Hugepage migration (v2)
in [Kernel]
|
Prev: [PATCH] DRM: Replace kmalloc/memset combos with kzalloc
Next: [PATCH] Break the kobject namespace defs into their own header
From: Christoph Lameter on 11 Aug 2010 09:20 On Tue, 10 Aug 2010, Naoya Horiguchi wrote: > There were two points of issue. > > * Dividing hugepage migration functions from original migration code. > This is to avoid complexity. > In present version, some high level migration routines are defined to handle > hugepage, but some low level routines (such as migrate_copy_page() etc.) > are shared with original migration code in order not to increase duplication. I hoped that we can avoid the branching for taking stuff off the lru and put pages back later to the lru. Seems that we still do that. Can be refactor the code in such a way that the lru handling cleanly isolates? There are now multiple use cases for migration that could avoid LRU handling even for PAGE_SIZE pages. > * Locking problem between direct I/O and hugepage migration > As a result of digging the race between hugepage I/O and hugepage migration, > (where hugepage I/O can be seen only in direct I/O,) > I noticed that without additional locking we can avoid this race condition > because in direct I/O we can get whether some subpages are under I/O or not > from reference count of the head page and hugepage migration safely fails > if some references remain. So no data lost should occurs on the migration > concurrent with direct I/O. Can you also avoid refcounts being increased during migration? The page lock is taken for the PAGE_SIZEd migration case. Can direct I/O be stopped by taking the page lock on the head page? If not then races can still occur. -- 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 12 Aug 2010 04:00 On Wed, Aug 11, 2010 at 08:09:59AM -0500, Christoph Lameter wrote: > On Tue, 10 Aug 2010, Naoya Horiguchi wrote: > > > There were two points of issue. > > > > * Dividing hugepage migration functions from original migration code. > > This is to avoid complexity. > > In present version, some high level migration routines are defined to handle > > hugepage, but some low level routines (such as migrate_copy_page() etc.) > > are shared with original migration code in order not to increase duplication. > > I hoped that we can avoid the branching for taking stuff off the lru and > put pages back later to the lru. Seems that we still do that. Can be > refactor the code in such a way that the lru handling cleanly isolates? > There are now multiple use cases for migration that could avoid LRU > handling even for PAGE_SIZE pages. OK. I'll rewrite isolation_lru_page() and putback_lru_page() like this: isolation_lru_page() for PAGE_SIZE page : delete from LRU list and get count for hugepage : just get count putback_lru_page() for PAGE_SIZE page : add to LRU list and put count for hugepage : just put count By doing this, we can avoid ugly code in individual migration callers. > > * Locking problem between direct I/O and hugepage migration > > As a result of digging the race between hugepage I/O and hugepage migration, > > (where hugepage I/O can be seen only in direct I/O,) > > I noticed that without additional locking we can avoid this race condition > > because in direct I/O we can get whether some subpages are under I/O or not > > from reference count of the head page and hugepage migration safely fails > > if some references remain. So no data lost should occurs on the migration > > concurrent with direct I/O. > > Can you also avoid refcounts being increased during migration? Yes. I think this will be done in above-mentioned refactoring. > The page > lock is taken for the PAGE_SIZEd migration case. Can direct I/O be stopped > by taking the page lock on the head page? If not then races can still > occur. Ah. I missed it. This patch only handles migration under direct I/O. For the opposite (direct I/O under migration) it's not true. I wrote additional patches (later I'll reply to this email) for solving locking problem. Could you review them? (Maybe these patches are beyond the scope of hugepage migration patch, so is it better to propose them separately?) 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: Christoph Lameter on 13 Aug 2010 08:50
On Thu, 12 Aug 2010, Naoya Horiguchi wrote: > > Can you also avoid refcounts being increased during migration? > > Yes. I think this will be done in above-mentioned refactoring. Thats not what I meant. Can you avoid other processors increasing refcounts (direct I/O etc?) on any page struct of the huge page while migration is running? > This patch only handles migration under direct I/O. > For the opposite (direct I/O under migration) it's not true. > I wrote additional patches (later I'll reply to this email) > for solving locking problem. Could you review them? Sure. > (Maybe these patches are beyond the scope of hugepage migration patch, > so is it better to propose them separately?) Migration with known races is really not what we want in the kernel. -- 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/ |