linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@saeurebad.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>, Andi Kleen <andi@firstfloor.org>,
	Yasunori Goto <y-goto@jp.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Christoph Lameter <clameter@sgi.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Siddha, Suresh B" <suresh.b.siddha@intel.com>
Subject: Re: [RFC][patch 2/5] mm: Node-setup agnostic free_bootmem()
Date: Wed, 16 Apr 2008 21:17:58 +0200	[thread overview]
Message-ID: <877iexfw2h.fsf@saeurebad.de> (raw)
In-Reply-To: <20080416184816.GA4400@elte.hu> (Ingo Molnar's message of "Wed, 16 Apr 2008 20:48:16 +0200")

Hi,

Ingo Molnar <mingo@elte.hu> writes:

> * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>> >  Yes, it should work well with cross nodes case.
>> >
>> >  but please add boundary check on free_bootmem_node too.
>> 
>> also please note: it will have problem span nodes box.
>> 
>> for example: node 0: 0-2g, 4-6g, node1: 2-4g, 6-8g. and if ramdisk sit 
>> creoss 2G boundary. you will only free the range before 2g.
>
> yes. Such systems _will_ become more common - so the "this is rare" 
> arguments are incorrect. bootmem has to be robust enough to deal with 
> it.

Ingo, I never doubted any of this, I was just asking more than once if
and when this might happen.  And I don't want the allocator become
fragile, just not completely ignorant about bogus input.

But the situation is still not clear for me.  Ingo, how are these
node spanning pfn ranges represented in the kernel?  How many node
descriptors will you have in the case Yinghai described and how will
they look like?

	Hannes

--
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>

  reply	other threads:[~2008-04-16 19:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-16 11:36 [RFC][patch 0/5] Bootmem fixes Johannes Weiner
2008-04-16 11:36 ` [RFC][patch 1/5] mm: Revert "mm: fix boundary checking in free_bootmem_core" Johannes Weiner
2008-04-16 17:49   ` Yinghai Lu
2008-04-16 11:36 ` [RFC][patch 2/5] mm: Node-setup agnostic free_bootmem() Johannes Weiner
2008-04-16 17:54   ` Yinghai Lu
2008-04-16 18:44     ` Yinghai Lu
2008-04-16 18:48       ` Ingo Molnar
2008-04-16 19:17         ` Johannes Weiner [this message]
2008-04-18  5:06           ` Yinghai Lu
2008-04-16 19:19     ` Johannes Weiner
2008-04-16 11:36 ` [RFC][patch 3/5] mm: Unexport __alloc_bootmem_core() Johannes Weiner
2008-04-16 11:36 ` [RFC][patch 4/5] mm: Normalize internal argument passing of bootmem data Johannes Weiner
2008-04-16 11:36 ` [RFC][patch 5/5] mm: Move bootmem descriptors definition to a single place Johannes Weiner
2008-04-16 17:30   ` Ralf Baechle
2008-04-17  9:36 ` [RFC][patch 0/5] Bootmem fixes KAMEZAWA Hiroyuki
2008-04-17 10:49   ` Johannes Weiner

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=877iexfw2h.fsf@saeurebad.de \
    --to=hannes@saeurebad.de \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=clameter@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=y-goto@jp.fujitsu.com \
    --cc=yhlu.kernel@gmail.com \
    /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