On Tue, Jul 06, 2010 at 09:13:37AM +0200, Andi Kleen wrote: > On Tue, Jul 06, 2010 at 12:33:42PM +0900, Naoya Horiguchi wrote: > > > There's more code that handles LRU in this file. Do they all handle huge pages > > > correctly? > > > > > > I also noticed we do not always lock all sub pages in the huge page. Now if > > > IO happens it will lock on subpages, not the head page. But this code > > > handles all subpages as a unit. Could this cause locking problems? > > > Perhaps it would be safer to lock all sub pages always? Or would > > > need to audit other page users to make sure they always lock on the head > > > and do the same here. > > > > > > Hmm page reference counts may have the same issue? > > > > If we try to implement paging out of hugepage in the future, we need to > > solve all these problems straightforwardly. But at least for now we can > > skirt them by not touching LRU code for hugepage extension. > > We need the page lock to avoid migrating pages that are currently > under IO. This can happen even without swapping when the process > manually starts IO. I see. I understood we should work on locking problem in now. I digged and learned hugepage IO can happen in direct IO from/to hugepage or coredump of hugepage user. We can resolve race between memory failure and IO by checking page lock and writeback flag, right? BTW I surveyed direct IO code, but page lock seems not to be taken. Am I missing something? (Before determining whether we lock all subpages or only headpage, I want to clarify how current code for non-hugepage resolves this problem.) Thanks, Naoya Horiguchi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>