研究科や研究室という組織についてはあんまりよく思ってはいないけど，研究自体は嫌いではないので，最近徐々に論文読みたい感じになってきている．
TCPまたはGPU関連で読みたい論文リストのメモ．
TCP
2002
WebサーバにおけるTCP処理をNICにオフロードするための設計と実装と評価．
SMP環境において専用のネットワークプロセッサを用いるアーキテクチャとクラスタ環境において専用のノードを用いるアーキテクチャの両方を評価
2005
前半部分は読んだ．
CUBICは高速ネットワーク環境に適したTCP輻輳制御アルゴリズムであり，BIC-TCPを改良したものである．
CUBICはBICのウィンドウサイズ制御を簡素化し，既存のTCPとの公平性およびRTT（Round Trip Time）公平性を改善している．
Linux2.6.19以降でデフォルトの輻輳制御アルゴリズムとして採用された．[該当コミット] (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=597811ec167fa01c926a0957a91d9e39baa30e64)
LinuxのTCP/IPスタック処理におけるsocket, TCP/UDP, IP and Ethernetの各レイヤーごとのパフォーマンス解析．
異なるシチュエーションにおけるそれぞれの性能ボトルネックを明らかにする．
TCP Offload Engineを有効にしたChelsio T110 10-Gigabitイーサネットアダプタのパフォーマンス評価．
-- ソケット層のマイクロベンチマークパフォーマンス評価
-- ソケットインタフェース上のMPI層のパフォーマンス評価
-- Apacheサーバを用いたアプリケーションレベルのパフォーマンス評価
10Gbpsのうち7.6Gbpsの性能．
(TCP Offload EngineとはTCPの一部ないし全ての処理のNIC（上記のイーサネットアダプタなど）にオフロードする仕組みのこと)
I/Oバス経由のデータアクセスやキャッシュミス，割り込みのオーバヘッドなどの処理はCPUコアの増加によるネットワークやI/Oバスの帯域幅のスケーラビリティを低下させる．
これらの処理に関わる命令を削減するために，TCP Offload Engineを採用した新しいホスト/NIC間のインタフェースを設計し，プロトタイプを実装した．
2006
Linux2.4および2.6におけるTCP/IPスタックをSMP環境で性能評価．
（SMPはSymmetric Multiprocessingの略で各コアに対称的に処理を割り振る．つまり，普通のマルチコア環境）
1TCPコネクションあたり1プロセッサのアーキテクチャが優位性を示す．
Linux2.4と2.6ではCPUのコストは大差ないが，2.6はカーネルのスケジューリングとロック機構が改良されているので，スケーラビリティに優れている．
NS2におけるTCP輻輳制御アルゴリズムの設計，実装および評価．
輻輳制御アルゴリズムの実装はLinux2.6と似ている．
NS2は有名なネットワークシミュレータでC++で実装されている．
次期バージョンであるNS3はPythonで実装されているらしいけど，ドキュメントが整ってなくて厳しい感じらしい．
これもLinux2.6のTCPスタックのパフォーマンスを数学モデルにより解析．
カーネルのプリエンプションがネットワーキングシステムに相互に悪影響があることに気づいた．
ボトルネックを解決するためのソリューションを提案する．
Red Hat社の中の人の論文．C10K問題 で有名な人でもある．
NICからアプリケーションレベルへデータをコピーするときに一旦カーネルにコピーしてからアプリケーションにコピーする問題のいくつかのソリューションを説明する．
2007
高エネルギー物理学の計算のようなグリッドコンピューティングにおいて，ペタバイトレベルのデータを転送する必要がある．
NICからアプリケーションに渡されるまでのLinuxのパケット受信の特性を解析するための数学モデルを開発．
2008
TCPの受信側に着目したパフォーマンス改善手法の提案．
もともと主要なボトルネックと言われていたデータコピーやチェックサム計算のような"1バイトあたりの処理"コストから，現在のプロセッサにおけるコネクション管理構造体へのメモリアクセスのような"1パケットあたりの処理"コストにボトルネックがシフトしている．
"1パケットあたりの処理"コストを削減するためにACKパケットの送信とパケットの結合をオフロードする．
ハードウェアへのオフロードはせずにソフトウェアのみによるパフォーマンス改善．
ネイティブのLinuxで45-67%の性能向上，Xenで仮想化されたゲストOSとしてのLinuxで86%の性能向上．
不明
多分2002年ぐらい．
本来カーネルで実装されているTCP/IPスタックをアプリケーション側で実装．
ソースコードはGitHubにあった．(https://github.com/jamesbw/tcp-daytona)
GPU
2009
テキスト検索アルゴリズムをGPUで高速化．
2010
ストレージシステムにおけるハッシュの計算をGPUにオフロードする話．
最近のストレージは，データの重複を排除するために，データをブロックに分割し，各ブロックに対してハッシュ値を計算しておき，ハッシュ値を比較することにより，データの重複を検出する．
GPU使えばCPUの100倍の性能でるよとか言ってるけど，CPU実装をちゃんと最適化すれば数倍の差程度でしかないよ，みたいな感じ．
GTX280とCorei7 970との比較．
単一または複数GPU構成のシステムにおけるタスクの負荷分散．
CUDA APIレベルよりももっと抽象的なAPIを用いていいかんじにタスクを分散する．
CUDAのスケジューラの改良的な感じ．
2011
OSのカーネルのいくつかの機能をGPUにより高速化できる．
OSのカーネルの補助的なプロセッサとしてGPUを使用するためのフレームワークを提案し，Linuxにおけるプロトタイプを示す．
2012
RDBMSにおけるクエリをCPUとGPUの両方で実行できるデータベースフレームワークの実装．
GPUメモリでのキャッシュが効くようにメモリマッピングを工夫して，GPUメモリの容量を超えるデータに対しても高速化できることを示す．
マルチコアCPUと比較して4倍から8倍の性能．
TCPとGPUの論文を輪講してると，カーネルという言葉がOSのカーネルなのかGPUプログラムの実行単位のことなのかを他人に説明するのがめんどくさくなってくる．
