All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Cc: Hirokazu Takahashi <taka@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, 4 Oct 2004 14:29:48 -0300	[thread overview]
Message-ID: <20041004172948.GM16374@logos.cnet> (raw)
In-Reply-To: <20041004040910.DCE4470A2D@sv1.valinux.co.jp>

On Mon, Oct 04, 2004 at 01:09:10PM +0900, IWAMOTO Toshihiro wrote:
> At Sat, 2 Oct 2004 15:33:49 -0300,
> Marcelo Tosatti wrote:
> > 
> > On Sat, Oct 02, 2004 at 06:30:15PM +0900, Hirokazu Takahashi wrote:
> > 3) At migrate_page_common you assume additional page references 
> > (page_migratable returning -EAGAIN) means the code should try to writeout 
> > the page.
> > 
> > Is that assumption always valid?
> > 
> > In theory there is no need to writeout pages when migrating them to 
> > other zones - they will be copied and the dirty information retained (either
> > in the PageDirty bit or radix tree tag). 
> 
> It's true only when page->private is NULL.  Otherwise writeback is
> necessary to free buffer_head.

You can move the buffer_head's also cant you? Adjusting bh->b_page etc.

Thats what migrate_page_buffer does, no?

Writting pages which contain buffer_head's on memory migration
is really, very bad. 

Imagine gigabytes of pages with buffer_head's. 

> > I just noticed you do that on further patches (migrate_page_buffer), but AFAICS 
> > the writeout remains. Why arent you using migrate_page_buffer yet?
> > 
> > I think the final aim should be to remove the need for "pageout()" 
> > completly.
> 
> Are you going to implement migrate_page_buffer for every file system?
> I don't think it's worthwhile.
> 
> > Questions: are there any documents on the memory hotplug userspace tools? 
> > Where can I find them?
> > 
> > Are Iwamoto's test programs available?
> 
> I've put them at the following URL, but I doubt they are useful for
> you; there are no documentation for them.
> 
> http://people.valinux.co.jp/~iwamoto/mh/tests/

I'll take a look thanks.

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Cc: Hirokazu Takahashi <taka@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, 4 Oct 2004 14:29:48 -0300	[thread overview]
Message-ID: <20041004172948.GM16374@logos.cnet> (raw)
In-Reply-To: <20041004040910.DCE4470A2D@sv1.valinux.co.jp>

On Mon, Oct 04, 2004 at 01:09:10PM +0900, IWAMOTO Toshihiro wrote:
> At Sat, 2 Oct 2004 15:33:49 -0300,
> Marcelo Tosatti wrote:
> > 
> > On Sat, Oct 02, 2004 at 06:30:15PM +0900, Hirokazu Takahashi wrote:
> > 3) At migrate_page_common you assume additional page references 
> > (page_migratable returning -EAGAIN) means the code should try to writeout 
> > the page.
> > 
> > Is that assumption always valid?
> > 
> > In theory there is no need to writeout pages when migrating them to 
> > other zones - they will be copied and the dirty information retained (either
> > in the PageDirty bit or radix tree tag). 
> 
> It's true only when page->private is NULL.  Otherwise writeback is
> necessary to free buffer_head.

You can move the buffer_head's also cant you? Adjusting bh->b_page etc.

Thats what migrate_page_buffer does, no?

Writting pages which contain buffer_head's on memory migration
is really, very bad. 

Imagine gigabytes of pages with buffer_head's. 

> > I just noticed you do that on further patches (migrate_page_buffer), but AFAICS 
> > the writeout remains. Why arent you using migrate_page_buffer yet?
> > 
> > I think the final aim should be to remove the need for "pageout()" 
> > completly.
> 
> Are you going to implement migrate_page_buffer for every file system?
> I don't think it's worthwhile.
> 
> > Questions: are there any documents on the memory hotplug userspace tools? 
> > Where can I find them?
> > 
> > Are Iwamoto's test programs available?
> 
> I've put them at the following URL, but I doubt they are useful for
> you; there are no documentation for them.
> 
> http://people.valinux.co.jp/~iwamoto/mh/tests/

I'll take a look thanks.
--
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>

  reply	other threads:[~2004-10-04 19:07 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-01 18:22 [RFC] memory defragmentation to satisfy high order allocations Marcelo Tosatti
2004-10-01 18:22 ` Marcelo Tosatti
2004-10-01 20:11 ` Andrew Morton
2004-10-01 20:11   ` Andrew Morton
2004-10-01 19:04   ` Marcelo Tosatti
2004-10-01 19:04     ` Marcelo Tosatti
2004-10-01 21:00     ` Andrew Morton
2004-10-01 21:00       ` Andrew Morton
2004-10-01 21:57     ` Dave Hansen
2004-10-01 21:57       ` Dave Hansen
2004-10-01 23:42       ` Marcelo Tosatti
2004-10-01 23:42         ` Marcelo Tosatti
2004-10-02  1:17         ` Andrew Morton
2004-10-02  1:17           ` Andrew Morton
2004-10-02  9:30         ` Hirokazu Takahashi
2004-10-02  9:30           ` Hirokazu Takahashi
2004-10-02 18:33           ` Marcelo Tosatti
2004-10-02 18:33             ` Marcelo Tosatti
2004-10-03  4:13             ` Hirokazu Takahashi
2004-10-03  4:13               ` Hirokazu Takahashi
2004-10-03 14:07               ` Marcelo Tosatti
2004-10-03 14:07                 ` Marcelo Tosatti
2004-10-03 18:35                 ` Hirokazu Takahashi
2004-10-03 18:35                   ` Hirokazu Takahashi
2004-10-03 19:21                   ` Trond Myklebust
2004-10-03 19:21                     ` Trond Myklebust
2004-10-03 20:03                     ` Hirokazu Takahashi
2004-10-03 20:03                       ` Hirokazu Takahashi
2004-10-03 20:44                       ` Trond Myklebust
2004-10-03 20:44                         ` Trond Myklebust
2004-10-04 13:02                         ` Hirokazu Takahashi
2004-10-04 13:02                           ` Hirokazu Takahashi
2004-10-04 17:24                   ` Marcelo Tosatti
2004-10-04 17:24                     ` Marcelo Tosatti
2004-10-05  2:53                     ` Hirokazu Takahashi
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
2004-10-04  3:24                   ` IWAMOTO Toshihiro
2004-10-04  2:22               ` Dave Hansen
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  4:09               ` IWAMOTO Toshihiro
2004-10-04 17:29               ` Marcelo Tosatti [this message]
2004-10-04 17:29                 ` Marcelo Tosatti
2004-10-02  2:30 ` Nick Piggin
2004-10-02  2:30   ` Nick Piggin
2004-10-02  3:08   ` Marcelo Tosatti
2004-10-02  3:08     ` Marcelo Tosatti
2004-10-04  8:15     ` Nick Piggin
2004-10-04  8:15       ` Nick Piggin
2004-10-02  2:41 ` Nick Piggin
2004-10-02  2:41   ` Nick Piggin
2004-10-02  3:50   ` Hirokazu Takahashi
2004-10-02  3:50     ` Hirokazu Takahashi
2004-10-02 16:06   ` Marcelo Tosatti
2004-10-02 16:06     ` Marcelo Tosatti
2004-10-04  2:38 ` Hiroyuki KAMEZAWA
2004-10-04  2:38   ` Hiroyuki KAMEZAWA
2004-10-04 17:32   ` Marcelo Tosatti
2004-10-04 17:32     ` Marcelo Tosatti
2004-10-04  6:58 ` Hiroyuki KAMEZAWA
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
  -- strict thread matches above, loose matches on Subject: below --
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=20041004172948.GM16374@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=arjanv@redhat.com \
    --cc=haveblue@us.ibm.com \
    --cc=iwamoto@valinux.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.