All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@saeurebad.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Ingo Molnar <mingo@elte.hu>, Yinghai Lu <yhlu.kernel@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 0/3] bootmem2 III
Date: Wed, 14 May 2008 21:12:47 +0200	[thread overview]
Message-ID: <87ve1gpumo.fsf@saeurebad.de> (raw)
In-Reply-To: <482990AB.7070905@firstfloor.org> (Andi Kleen's message of "Tue, 13 May 2008 14:59:23 +0200")

Hi Andi,

Andi Kleen <andi@firstfloor.org> writes:

>> I was wondering yesterday if it would be feasible to enforce
>> contiguousness for nodes.
>
> And lose the memory? That would make people not happy.

No, one node descriptor per contiguous block on the physical node.

So this setup:

node 0: 0-2G, 4-6G
node 1: 2-4G, 6-8G

would have 4 pgdats.

>> So that arch-code does not create one pgdat
>> for each node but one for each contiguous block.  I have not yet looked
>> deeper into it, but I suspect that other mm code has similar problems
>> with nodes spanning other nodes.
>
> I wouldn't think so. At least sparse memory with large holes is not that
> uncommon in the non x86 world.

I do not quite understand.  Holes are not the problem - the overlapping
is.

The current bootmem allocator for example might pass the same pfn twice
to the buddy allocator when two nodes overlap.  And I don't know if
other mm code has the same problem.

	Hannes

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@saeurebad.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Ingo Molnar <mingo@elte.hu>, Yinghai Lu <yhlu.kernel@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 0/3] bootmem2 III
Date: Wed, 14 May 2008 21:12:47 +0200	[thread overview]
Message-ID: <87ve1gpumo.fsf@saeurebad.de> (raw)
In-Reply-To: <482990AB.7070905@firstfloor.org> (Andi Kleen's message of "Tue, 13 May 2008 14:59:23 +0200")

Hi Andi,

Andi Kleen <andi@firstfloor.org> writes:

>> I was wondering yesterday if it would be feasible to enforce
>> contiguousness for nodes.
>
> And lose the memory? That would make people not happy.

No, one node descriptor per contiguous block on the physical node.

So this setup:

node 0: 0-2G, 4-6G
node 1: 2-4G, 6-8G

would have 4 pgdats.

>> So that arch-code does not create one pgdat
>> for each node but one for each contiguous block.  I have not yet looked
>> deeper into it, but I suspect that other mm code has similar problems
>> with nodes spanning other nodes.
>
> I wouldn't think so. At least sparse memory with large holes is not that
> uncommon in the non x86 world.

I do not quite understand.  Holes are not the problem - the overlapping
is.

The current bootmem allocator for example might pass the same pfn twice
to the buddy allocator when two nodes overlap.  And I don't know if
other mm code has the same problem.

	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-05-14 19:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-09 15:17 [PATCH 0/3] bootmem2 III Johannes Weiner
2008-05-09 15:17 ` Johannes Weiner
2008-05-09 15:17 ` [PATCH 1/3] mm: Make NR_NODE_MEMBLKS global Johannes Weiner
2008-05-09 15:17   ` Johannes Weiner
2008-05-09 15:17 ` [PATCH 2/3] mm: bootmem2 Johannes Weiner
2008-05-09 15:17   ` Johannes Weiner
2008-05-09 15:17 ` [PATCH 3/3] x86: Migrate X86_32 to bootmem2 Johannes Weiner
2008-05-09 15:17   ` Johannes Weiner
2008-05-09 18:40 ` [PATCH 0/3] bootmem2 III Andi Kleen
2008-05-09 18:40   ` Andi Kleen
2008-05-11 19:18   ` Johannes Weiner
2008-05-11 19:18     ` Johannes Weiner
2008-05-11 20:18     ` Andi Kleen
2008-05-11 20:18       ` Andi Kleen
2008-05-13 12:40       ` Johannes Weiner
2008-05-13 12:40         ` Johannes Weiner
2008-05-13 12:59         ` Andi Kleen
2008-05-13 12:59           ` Andi Kleen
2008-05-14 19:12           ` Johannes Weiner [this message]
2008-05-14 19:12             ` Johannes Weiner
2008-05-15 19:12         ` Andy Whitcroft
2008-05-15 19:12           ` Andy Whitcroft
2008-05-16 20:42           ` Johannes Weiner
2008-05-16 20:42             ` 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=87ve1gpumo.fsf@saeurebad.de \
    --to=hannes@saeurebad.de \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    --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 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.