hugetlb: hugepage migration core
in [Kernel]
|
From: Naoya Horiguchi on 7 Jul 2010 02:50 On Tue, Jul 06, 2010 at 11:02:04AM -0500, Christoph Lameter wrote: > On Tue, 6 Jul 2010, Naoya Horiguchi wrote: > > > Hmm, this chunk need to be fixed because I had too specific assumption. > > The list passed to migrate_pages() has only one page or one hugepage in > > page migration kicked by soft offline, but it's not the case in general case. > > Since hugepage is not linked to LRU list, we had better simply skip > > putback_lru_pages(). > > Maybe write a migrate_huge_page() function instead? The functionality is > materially different since we are not juggling things with the lru. OK. I'll try to devide functions for hugepage in the next turn. Thanks, Naoya Horiguchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 7 Jul 2010 05:30 > 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? Yes, but we have to make sure it's in the same page. As I understand the IO locking does not use the head page, that means migration may need to lock all the sub pages. Or fix IO locking to use head pages? > > BTW I surveyed direct IO code, but page lock seems not to be taken. > Am I missing something? That's expected I believe because applications are supposed to coordinate for direct IO (but then direct IO also drops page cache). But page lock is used to coordinate in the page cache for buffered IO. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Naoya Horiguchi on 8 Jul 2010 01:50 On Wed, Jul 07, 2010 at 11:27:19AM +0200, Andi Kleen wrote: > > 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? > > Yes, but we have to make sure it's in the same page. > > As I understand the IO locking does not use the head page, that > means migration may need to lock all the sub pages. > > Or fix IO locking to use head pages? > > > > BTW I surveyed direct IO code, but page lock seems not to be taken. > > Am I missing something? > > That's expected I believe because applications are supposed to coordinate > for direct IO (but then direct IO also drops page cache). > > But page lock is used to coordinate in the page cache for buffered IO. This page cache is located on non-hugepage, isn't it? If so, buffered IO is handled in the same manner as done for non-hugepage. I think "hugepage under IO" is realized only in direct IO for now. Direct IO is issued in page unit even if the target page is in hugepage, so locking each subpages separately looks natural for me than auditing head page. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 8 Jul 2010 03:00
> This page cache is located on non-hugepage, isn't it? Yes. > If so, buffered IO is handled in the same manner as done for non-hugepage. > I think "hugepage under IO" is realized only in direct IO for now. > > Direct IO is issued in page unit even if the target page is in hugepage, > so locking each subpages separately looks natural for me than auditing > head page. Ok. Would need to make sure lock ordering is correctly handled all the time. If there's any code that locks multiple pages "backwards" and the migration code locks it forward there might be a problem. Maybe it's not a problem though. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |