プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

SLUBが遅い原因がだいたい分かったような このエントリーをはてなブックマークに追加

2.6.23からデフォルトアロケータとなったSLUBであるかTPC-Cなど、いくつかのベンチで従来のSLABより遅いことが知られていた。
で、個人的には自分がhackbenchを多用することもあり、SLUBがhackbenchでしばしばSLABの10倍以上遅いのは気になっていた。
んで、LKMLで議論していたのだが、だいたい原因がわかったような気がする。

以下はhackbenchを実行した直後のmeminfoの抜粋。
SLUBのほうが1G以上余計にメモリを使っていることが分かる。メモリ消費量が大きいってのは、余計なスワップを誘発する可能性があるわけで、パフォーマンスを落とす原因になりうる


MemTotal: 7701376 kB
Slab: 123840 kB
SReclaimable: 30272 kB
SUnreclaim: 93568 kB


MemTotal: 7701376 kB
Slab: 1591680 kB
SReclaimable: 12608 kB
SUnreclaim: 1579072 kB

んで、なんでそうなるかというとslabinfoコマンドから分かって

% slabinfo
Name Objects Objsize Space Slabs/Part/Cpu O/S O %Fr %Ef Flg
:t-0000128 28739 128 1.3G 20984/20984/8 512 0 99 0 *

128byte object用slabが28739 objectしかないのに、20984 slabつくっている。
つまりほとんど1 obj につき1slab.

これは直接的には以下のコードが原因

static inline
int lock_and_freeze_slab(struct kmem_cache_node *n, struct page *page)
{
if (slab_trylock(page)) {
list_del(&page->lru);
n->nr_partial--;
__SetPageSlubFrozen(page);
return 1;
}
return 0;
}


glibcもそうなんだけど、slubもアロケートにいくつか順序があって
1.CPU毎のオレ専用 free listを探す。これはロック不要なので超速い
2.ダメなら途中まで使っているslabを使おうとtrylock
3.全部ロックがとれなかったら新しいslabを作る

となっているんだけど、hackbenchだと競合が激しすぎてtrylockが失敗しまくり、レアイベントの予定だった3が頻発しちゃったわけだね。

なので、解決としては2と3の間にもうワンクッション、メモリを新しく確保せずになんとかがんばるメソッドを挿入できればよい。となる。
2を直接かえちゃうと、うまくいってたケースで遅くなっちゃうからね。

間違ってるかもしれないので、もうちょっとCristoph Lameterあたりと議論が必要だが、前には進んでいるのでRHEL6までには解決できるんではなかろうか。
関連記事


linux | 【2008-08-14(Thu) 00:13:50】 | Trackback:(0) | Comments:(1)
コメント

なんかえらい人からリンク貼られてしまったので、続報書いておこう。
この問題は、すでに修正済みなので気にする必要ないはずですす。
2010-05-15 土 13:18:16 | URL | kosaki #- [ 編集]
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。