Re: [PATCH] mm: use a radix-tree to make do_move_pages() complexity linear

All of lore.kernel.org
 help / color / mirror / Atom feed

From: Christoph Lameter <cl@linux-foundation.org>
To: Brice Goglin <Brice.Goglin@inria.fr>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	nathalie.furmento@labri.fr
Subject: Re: [PATCH] mm: use a radix-tree to make do_move_pages() complexity linear
Date: Mon, 13 Oct 2008 09:09:30 -0700	[thread overview]
Message-ID: <48F372BA.7020505@linux-foundation.org> (raw)
In-Reply-To: <48F069B8.6050709@inria.fr>

Brice Goglin wrote:
> * One thing that bothers me is move_pages() returning -ENOENT when no
> page are given to migrate_pages(). I don't see why having 100/100 pages
> not migrated would return a different error than having only 99/100
> pages not migrated. We have the status array to place -ENOENT for all
> these pages. If the user doesn't know where his pages are allocated, he
> shouldn't get a different return value depending on how many pages were
> already on the right node. And actually, this convention makes
> user-space application harder to write since you need to treat -ENOENT
> as a success unless you already knew for sure where your pages were
> allocated. And the big thing is that this convention makes the chunking
> painfully/uselessly more complex. Breaking user-ABI is bad, but fixing
> crazy ABI...
>   
I do not think that move_pages() is used that frequently. Changing the 
API slightly as you suggest would not be that big of a deal.

WARNING: multiple messages have this Message-ID (diff)

From: Christoph Lameter <cl@linux-foundation.org>
To: Brice Goglin <Brice.Goglin@inria.fr>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	nathalie.furmento@labri.fr
Subject: Re: [PATCH] mm: use a radix-tree to make do_move_pages() complexity linear
Date: Mon, 13 Oct 2008 09:09:30 -0700	[thread overview]
Message-ID: <48F372BA.7020505@linux-foundation.org> (raw)
In-Reply-To: <48F069B8.6050709@inria.fr>

Brice Goglin wrote:
> * One thing that bothers me is move_pages() returning -ENOENT when no
> page are given to migrate_pages(). I don't see why having 100/100 pages
> not migrated would return a different error than having only 99/100
> pages not migrated. We have the status array to place -ENOENT for all
> these pages. If the user doesn't know where his pages are allocated, he
> shouldn't get a different return value depending on how many pages were
> already on the right node. And actually, this convention makes
> user-space application harder to write since you need to treat -ENOENT
> as a success unless you already knew for sure where your pages were
> allocated. And the big thing is that this convention makes the chunking
> painfully/uselessly more complex. Breaking user-ABI is bad, but fixing
> crazy ABI...
>   
I do not think that move_pages() is used that frequently. Changing the 
API slightly as you suggest would not be that big of a deal.

--
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:"dont@kvack.org"> email@kvack.org </a>

next prev parent reply	other threads:[~2008-10-13 14:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09 12:32 [PATCH] mm: use a radix-tree to make do_move_pages() complexity linear Brice Goglin
2008-10-09 12:32 ` Brice Goglin
2008-10-10 19:50 ` Andrew Morton
2008-10-10 19:50   ` Andrew Morton
2008-10-10 20:11   ` Brice Goglin
2008-10-10 20:11     ` Brice Goglin
2008-10-10 20:32     ` Christoph Lameter
2008-10-10 20:32       ` Christoph Lameter
2008-10-11  8:54       ` Brice Goglin
2008-10-11  8:54         ` Brice Goglin
2008-10-11  8:58         ` Nick Piggin
2008-10-11  8:58           ` Nick Piggin
2008-10-11  9:19           ` Brice Goglin
2008-10-11  9:19             ` Brice Goglin
2008-10-13 16:09         ` Christoph Lameter [this message]
2008-10-13 16:09           ` Christoph Lameter
2008-10-10 20:59     ` Brice Goglin
2008-10-10 20:59       ` Brice Goglin

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=48F372BA.7020505@linux-foundation.org \
    --to=cl@linux-foundation.org \
    --cc=Brice.Goglin@inria.fr \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nathalie.furmento@labri.fr \
    /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.