> On Mon, Jun 21, 2010 at 10:05:26PM +1000, Nick Piggin wrote: > > Andrea Arcangeli Transparent hugepages > > Sure fine on my side. I got a proposal accepted for presentation at > KVM Forum 2010 about it too the days after the VM summit too. > > > KOSAKI Motohiro get_user_pages vs COW problem > > Just a side note, not sure exactly what is meant to be discussed about > this bug, considering the fact this is still unsolved isn't technical > problem as there were plenty of fixes available, and the one that seem > to had better chance to get included was the worst one in my view, as > it tried to fix it in a couple of gup caller (but failed, also because > finding all put_page pin release is kind of a pain as they're spread > all over the place and not identified as gup_put_page, and in addition > to the instability and lack of completeness of the fix, it was also > the most inefficient as it added unnecessary and coarse locking) plus > all gup callers are affected, not just a few. I normally call it gup > vs fork race. Luckily not all threaded apps uses O_DIRECT and fork and > pretend to do the direct-io in different sub-page chunks of the same > page from different threads (KVM would probably be affected if it > didn't use MADV_DONTFORK on the O_DIRECT memory, as it might run fork > to execute some network script when adding an hotplug pci net device > for example). But surely we can discuss the fix we prefer for this > bug, or at least we can agree it needs fixing. If people don't want this. I'm ok to drop this. In my personal concern most important topics are following four topics. (again it's only _my_ concern) Rik van Riel Memory management under virtualization (with KVM) Andrea Arcangeli Transparent hugepages - mmap_sem scalability, again - Direct reclaim, direct writeback problems -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
