linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Hirokazu Takahashi <taka@valinux.co.jp>,
	iwamoto@valinux.co.jp, haveblue@us.ibm.com, akpm@osdl.org,
	linux-mm@kvack.org, piggin@cyberone.com.au, arjanv@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] memory defragmentation to satisfy high order allocations
Date: Mon, 04 Oct 2004 12:24:25 +0900	[thread overview]
Message-ID: <20041004032425.AD3F470A2D@sv1.valinux.co.jp> (raw)
In-Reply-To: <20041003140723.GD4635@logos.cnet>

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  parent reply	other threads:[~2004-10-04  3:24 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-01 18:22 Marcelo Tosatti
2004-10-01 20:11 ` Andrew Morton
2004-10-01 19:04   ` Marcelo Tosatti
2004-10-01 21:00     ` Andrew Morton
2004-10-01 21:57     ` Dave Hansen
2004-10-01 23:42       ` Marcelo Tosatti
2004-10-02  1:17         ` Andrew Morton
2004-10-02  9:30         ` Hirokazu Takahashi
2004-10-02 18:33           ` Marcelo Tosatti
2004-10-03  4:13             ` Hirokazu Takahashi
2004-10-03 14:07               ` Marcelo Tosatti
2004-10-03 18:35                 ` Hirokazu Takahashi
2004-10-03 19:21                   ` Trond Myklebust
2004-10-03 20:03                     ` Hirokazu Takahashi
2004-10-03 20:44                       ` Trond Myklebust
2004-10-04 13:02                         ` Hirokazu Takahashi
2004-10-04 17:24                   ` Marcelo Tosatti
2004-10-05  2:53                     ` Hirokazu Takahashi
2004-10-07 12:06                       ` Marcelo Tosatti
2004-10-08  7:00                         ` Hirokazu Takahashi
2004-10-08 10:00                           ` Marcelo Tosatti
2004-10-08 12:23                             ` Hirokazu Takahashi
2004-10-08 12:41                               ` Marcelo Tosatti
2004-10-08 16:52                                 ` Hirokazu Takahashi
2004-10-08 15:36                                   ` Marcelo Tosatti
2004-10-12 10:56                                     ` IWAMOTO Toshihiro
2004-10-12 10:35                                       ` Marcelo Tosatti
2004-10-12 17:55                                         ` Hirokazu Takahashi
2004-10-12 14:26                                       ` Martin J. Bligh
2004-10-12 12:17                                         ` Marcelo Tosatti
2004-10-12 15:01                                         ` Dave Hansen
2004-10-04  3:24                 ` IWAMOTO Toshihiro [this message]
2004-10-04  2:22               ` Dave Hansen
2004-10-05 16:46               ` [PATCH] mhp: transfer dirty tag at radix_tree_replace Marcelo Tosatti
2004-10-05 18:35                 ` Dave Hansen
2004-10-06  7:39                 ` Hirokazu Takahashi
2004-10-08  8:15                   ` Hirokazu Takahashi
2004-10-08 20:36                     ` Marcelo Tosatti
2004-10-04  4:09             ` [RFC] memory defragmentation to satisfy high order allocations IWAMOTO Toshihiro
2004-10-04 17:29               ` Marcelo Tosatti
2004-10-02  2:30 ` Nick Piggin
2004-10-02  3:08   ` Marcelo Tosatti
2004-10-04  8:15     ` Nick Piggin
2004-10-02  2:41 ` Nick Piggin
2004-10-02  3:50   ` Hirokazu Takahashi
2004-10-02 16:06   ` Marcelo Tosatti
2004-10-04  2:38 ` Hiroyuki KAMEZAWA
2004-10-04 17:32   ` Marcelo Tosatti
2004-10-04  6:58 ` Hiroyuki KAMEZAWA
2004-10-07 15:58   ` memory hotplug and mem= Marcelo Tosatti
2004-10-07 18:36     ` Dave Hansen
2004-10-07 17:01       ` Marcelo Tosatti
2004-10-07 19:10         ` Dave Hansen
2004-10-07 20:25         ` Dave Hansen
2004-10-11 16:40 [RFC] memory defragmentation to satisfy high order allocations linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041004032425.AD3F470A2D@sv1.valinux.co.jp \
    --to=iwamoto@valinux.co.jp \
    --cc=akpm@osdl.org \
    --cc=arjanv@redhat.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=piggin@cyberone.com.au \
    --cc=taka@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox