Messages in this thread | | | Date | Mon, 04 Oct 2004 12:24:25 +0900 | From | IWAMOTO Toshihiro <> | Subject | Re: [RFC] memory defragmentation to satisfy high order allocations |
| |
At Sun, 3 Oct 2004 11:07:23 -0300, Marcelo Tosatti wrote: > > On Sun, Oct 03, 2004 at 01:13:38PM +0900, Hirokazu Takahashi wrote: > > > 2) > > > At migrate_onepage you add anonymous pages which aren't swap allocated > > > to the swap cache > > > + /* > > > + * Put the page in a radix tree if it isn't in the tree yet. > > > + */ > > > +#ifdef CONFIG_SWAP > > > + if (PageAnon(page) && !PageSwapCache(page)) > > > + if (!add_to_swap(page, GFP_KERNEL)) { > > > + unlock_page(page); > > > + return ERR_PTR(-ENOSPC); > > > + } > > > +#endif /* CONFIG_SWAP */ > > > > > > Why's that? You can copy anonymous pages without adding them to swap (thats > > > what the patch I posted does). > > > > The reason is to guarantee that any anonymous page can be migrated anytime. > > I want to block newly occurred accesses to the page during the migration > > because it can't be migrated if there remain some references on it by > > system calls, direct I/O and page faults. > > It would be nice if we could block pte faults in a way such to not need > adding each anonymous page to swap. It can be too costly if you have a lot memory > and it makes the whole operation dependable on swap size (if you dont have enough > swap, you're dead). > > Maybe hold mm->page_table_lock (might be too costly in terms of CPU time, but since > migration is not a common operation anyway), or create a semaphore?
I chose the swap cache based implementation in order to minimize slowdown of the normal code path. (I thought there's zero code addition on the normal pagefault path when I designed this, but it's no longer true...)
If we can agree on adding a new lock, there might be a better implementation.
-- IWAMOTO Toshihiro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |