スポンサー広告 | 【--------(--) --:--:--】 | 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()
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
Andreaを見かねて助け船を出したつもりが、Linusから「むしろ kosaki パッチをマージすべきじゃね？」とか言われてアゴがはずれそう。