Re: [RFC] memory defragmentation to satisfy high order allocations
From: IWAMOTO Toshihiro (iwamoto_at_valinux.co.jp)
Date: 10/04/04
- Previous message: Jim Nelson: "Re: patches inline in mail"
- In reply to: Marcelo Tosatti: "Re: [RFC] memory defragmentation to satisfy high order allocations"
- Next in thread: Dave Hansen: "Re: [RFC] memory defragmentation to satisfy high order allocations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 04 Oct 2004 12:24:25 +0900 To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
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/
- Previous message: Jim Nelson: "Re: patches inline in mail"
- In reply to: Marcelo Tosatti: "Re: [RFC] memory defragmentation to satisfy high order allocations"
- Next in thread: Dave Hansen: "Re: [RFC] memory defragmentation to satisfy high order allocations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
