プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

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


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

自分の書いたパッチではまる このエントリーをはてなブックマークに追加

On Tue, 17 Mar 2009, Nick Piggin wrote:
> > Yes, my patch isn't realy solusion.
> > Andrea already pointed out that it's not O_DIRECT issue, it's gup vs fork
> > issue. *and* my patch is crazy slow :)
>
> Well, it's an interesting question. I'd say it probably is more than
> just O_DIRECT. vmsplice too, for example (which I think is much harder
> to fix this way because the pages are retired by the other end of
> the pipe, so I don't think you can hold a lock across it).

Well, only the "fork()" has the race problem.

So having a fork-specific lock (but not naming it by directio) actually
does make sense. The fork is much less performance-critical than most
random mmap_sem users - and doesn't have the same scalability issues
either (ie people probably _do_ want to do mmap/munmap/brk concurrently
with gup lookup, but there's much less worry about concurrent fork()
performance).

It doesn't necessarily make the general problem go away, but it makes the
_particular_ race between get_user_pages() and fork() go away. Then you
can do per-page flags or whatever and not have to worry about concurrent
lookups.

Linus


Andreaを見かねて助け船を出したつもりが、Linusから「むしろ kosaki パッチをマージすべきじゃね?」とか言われてアゴがはずれそう。
ごめんよAndrea,そんなつもりじゃなかったんだよー


関連記事


linux | 【2009-03-17(Tue) 11:16:28】 | Trackback:(0) | Comments:(0)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。