プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

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


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

writeではtmpfsよりpage cacheが遅い理由 このエントリーをはてなブックマークに追加

注意: 以下の記事は完全に間違っています。ext3はflushメソッドがNULLなので、closeのときにfsyncされないよん。ごめんなさいm(_ _)m

http://d.hatena.ne.jp/naoya/20070521/1179754203

のコメント欄

naoya 『read はキャッシュに載ってれば常にメモリアクセスのみで済むけど write はページに dirty フラグを立ててプロセスに制御が戻ったあと、pdflush がどこかのタイミングでディスクに書き出しして必ず物理的にディスクにアクセスしますよね。

その時の排他処理周りなんじゃないかなあと思いますが、その辺が実ははっきりしないんですよね。だいぶ追ってみてはみたんですが。』 (2007/05/22 00:24)

naoya 『普通に考えれば write はディスク更新があるから云々というのは想像がつくけど、じゃあ具体的にページをディスクに書き出す処理がたくさん発生した場合に、OS がどこの処理を行ったときに write してるユーザープロセスに影響を与えてしまうのかというのが正確に説明できない。』 (2007/05/22 00:26)



Linuxのcloseは暗にfsyncするから、ここであげられている

100000回繰り返し
open
8K write
close

というパターンだとfsyncコストが見えちゃうので良くないんじゃないかな

naoya氏がなんで突然カーネルの世界にはまりだしたのか知らないけど、まずはメデタイ\(^o^)/


関連記事


blog | 【2007-05-22(Tue) 11:18:43】 | Trackback:(1) | Comments:(1)
コメント

いろいろなサイト巡って気に入ったサイトだけランキングクリックして廻ってます。
素敵なサイトですね。ランキングクリック入れときますね。では又、遊びにきます。
2007-06-10 日 02:25:59 | URL | とも #- [ 編集]
Linuxのcloseは暗にfsyncするから、ここであげられている 100000回繰り返し open 8K write close というパターンだとfsyncコストが見えちゃうので良くないんじゃないかな 革命の日々! とのことで、そうなのか! と思ったので例によって深追いしてみました。 まず fsync(2)
【2007-05-22 Tue 15:21:12】 | naoyaのはてなダイアリー
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。