From: Dave Hansen <hansendc@us.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Martin Bligh <mbligh@google.com>,
linux-mm@kvack.org, Andi Kleen <ak@suse.de>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH 1/2] Generic Virtual Memmap suport for SPARSEMEM
Date: Mon, 02 Apr 2007 14:22:04 -0700 [thread overview]
Message-ID: <1175548924.22373.109.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0704021351590.1224@schroedinger.engr.sgi.com>
On Mon, 2007-04-02 at 14:00 -0700, Christoph Lameter wrote:
> On Mon, 2 Apr 2007, Dave Hansen wrote:
> > > + } else
> > > + return __alloc_bootmem_node(NODE_DATA(node), size, size,
> > > + __pa(MAX_DMA_ADDRESS));
> > > +}
> >
> > Hmmmmmmm. Can we combine this with sparse_index_alloc()? Also, why not
> > just use the slab for this?
>
> Use a slab for page sized allocations? No.
Why not? We use it above for sparse_index_alloc() and if it is doing
something wrong, I'd love to fix it. Can you elaborate?
> > Let's get rid of the _block() part, too. I'm not sure it does any good.
> > At least make it _bytes() so that we know what the units are. Also, if
> > you're just going to round up internally and _not_ use the slab, can you
> > just make the argument in pages, or even order?
>
> Its used for page sized allocations.
Ok, then let's make it take pages of some kind or its argument.
> > Can you think of any times when we'd want that BUG_ON() to be a
> > WARN_ON(), instead? I can see preferring having my mem_map[] on the
> > wrong node than hitting a BUG().
>
> We should probably have some error handling there instead of the BUG.
>
> > > +#ifndef ARCH_POPULATES_VIRTUAL_MEMMAP
> > > +/*
> > > + * Virtual memmap populate functionality for architectures that support
> > > + * PMDs for huge pages like i386, x86_64 etc.
> > > + */
> >
> > How about:
> >
> > /*
> > * Virtual memmap support for architectures that use Linux pagetables
> > * natively in hardware, and support mapping huge pages with PMD
> > * entries.
> > */
> >
> > It wouldn't make sense to map the vmemmap area with Linux pagetables on
> > an arch that didn't use them in hardware, right? So, perhaps this
> > doesn't quite belong in mm/sparse.c. Perhaps we need
> > arch/x86/sparse.c. ;)
>
> I just extended this in V2 to also work on IA64. Its pretty generic.
Can you extend it to work on ppc? ;)
You haven't posted V2, right?
> >
> > map = alloc_remap(nid, sizeof(struct page) * PAGES_PER_SECTION);
> > if (map)
> > return map;
> >
> > + map = alloc_vmemmap(map, PAGES_PER_SECTION, nid);
> > + if (map)
> > + return map;
> > +
> > map = alloc_bootmem_node(NODE_DATA(nid),
> > sizeof(struct page) * PAGES_PER_SECTION);
> > if (map)
> > return map;
> >
> > Then, do whatever magic you want in alloc_vmemmap().
>
> That would break if alloc_vmemmap returns NULL because it cannot allocate
> memory.
OK, that makes sense. However, it would still be nice to hide that
#ifdef somewhere that people are a bit less likely to run into it. It's
just one #ifdef, so if you can kill it, great. Otherwise, they pile up
over time and _do_ cause real readability problems.
-- Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <hansendc@us.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Martin Bligh <mbligh@google.com>,
linux-mm@kvack.org, Andi Kleen <ak@suse.de>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH 1/2] Generic Virtual Memmap suport for SPARSEMEM
Date: Mon, 02 Apr 2007 14:22:04 -0700 [thread overview]
Message-ID: <1175548924.22373.109.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0704021351590.1224@schroedinger.engr.sgi.com>
On Mon, 2007-04-02 at 14:00 -0700, Christoph Lameter wrote:
> On Mon, 2 Apr 2007, Dave Hansen wrote:
> > > + } else
> > > + return __alloc_bootmem_node(NODE_DATA(node), size, size,
> > > + __pa(MAX_DMA_ADDRESS));
> > > +}
> >
> > Hmmmmmmm. Can we combine this with sparse_index_alloc()? Also, why not
> > just use the slab for this?
>
> Use a slab for page sized allocations? No.
Why not? We use it above for sparse_index_alloc() and if it is doing
something wrong, I'd love to fix it. Can you elaborate?
> > Let's get rid of the _block() part, too. I'm not sure it does any good.
> > At least make it _bytes() so that we know what the units are. Also, if
> > you're just going to round up internally and _not_ use the slab, can you
> > just make the argument in pages, or even order?
>
> Its used for page sized allocations.
Ok, then let's make it take pages of some kind or its argument.
> > Can you think of any times when we'd want that BUG_ON() to be a
> > WARN_ON(), instead? I can see preferring having my mem_map[] on the
> > wrong node than hitting a BUG().
>
> We should probably have some error handling there instead of the BUG.
>
> > > +#ifndef ARCH_POPULATES_VIRTUAL_MEMMAP
> > > +/*
> > > + * Virtual memmap populate functionality for architectures that support
> > > + * PMDs for huge pages like i386, x86_64 etc.
> > > + */
> >
> > How about:
> >
> > /*
> > * Virtual memmap support for architectures that use Linux pagetables
> > * natively in hardware, and support mapping huge pages with PMD
> > * entries.
> > */
> >
> > It wouldn't make sense to map the vmemmap area with Linux pagetables on
> > an arch that didn't use them in hardware, right? So, perhaps this
> > doesn't quite belong in mm/sparse.c. Perhaps we need
> > arch/x86/sparse.c. ;)
>
> I just extended this in V2 to also work on IA64. Its pretty generic.
Can you extend it to work on ppc? ;)
You haven't posted V2, right?
> >
> > map = alloc_remap(nid, sizeof(struct page) * PAGES_PER_SECTION);
> > if (map)
> > return map;
> >
> > + map = alloc_vmemmap(map, PAGES_PER_SECTION, nid);
> > + if (map)
> > + return map;
> > +
> > map = alloc_bootmem_node(NODE_DATA(nid),
> > sizeof(struct page) * PAGES_PER_SECTION);
> > if (map)
> > return map;
> >
> > Then, do whatever magic you want in alloc_vmemmap().
>
> That would break if alloc_vmemmap returns NULL because it cannot allocate
> memory.
OK, that makes sense. However, it would still be nice to hide that
#ifdef somewhere that people are a bit less likely to run into it. It's
just one #ifdef, so if you can kill it, great. Otherwise, they pile up
over time and _do_ cause real readability problems.
-- Dave
--
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:[~2007-04-02 21:22 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-01 7:10 [PATCH 1/2] Generic Virtual Memmap suport for SPARSEMEM Christoph Lameter
2007-04-01 7:10 ` Christoph Lameter
2007-04-01 7:10 ` [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL Christoph Lameter
2007-04-01 7:10 ` Christoph Lameter
2007-04-01 7:11 ` Christoph Lameter
2007-04-01 7:11 ` Christoph Lameter
2007-04-01 10:46 ` Andi Kleen
2007-04-01 10:46 ` Andi Kleen
2007-04-02 15:37 ` Christoph Lameter
2007-04-02 15:37 ` Christoph Lameter
2007-04-02 15:44 ` Andi Kleen
2007-04-02 15:44 ` Andi Kleen
2007-04-02 15:51 ` Martin J. Bligh
2007-04-02 15:51 ` Martin J. Bligh
2007-04-02 15:54 ` Christoph Lameter
2007-04-02 15:54 ` Christoph Lameter
2007-04-02 17:14 ` Andi Kleen
2007-04-02 17:14 ` Andi Kleen
2007-04-02 17:34 ` Christoph Lameter
2007-04-02 17:34 ` Christoph Lameter
2007-04-02 19:54 ` Dave Hansen
2007-04-02 19:54 ` Dave Hansen
2007-04-02 20:11 ` Christoph Lameter
2007-04-02 20:11 ` Christoph Lameter
2007-04-02 20:13 ` Dave Hansen
2007-04-02 20:13 ` Dave Hansen
2007-04-02 20:30 ` Christoph Lameter
2007-04-02 20:30 ` Christoph Lameter
2007-04-02 20:38 ` Martin Bligh
2007-04-02 20:38 ` Martin Bligh
2007-04-02 20:51 ` Christoph Lameter
2007-04-02 20:51 ` Christoph Lameter
2007-04-05 11:50 ` Andy Whitcroft
2007-04-05 11:50 ` Andy Whitcroft
2007-04-05 18:27 ` Christoph Lameter
2007-04-05 18:27 ` Christoph Lameter
2007-04-07 22:06 ` [PATCH 1/4] x86_64: (SPARSE_VIRTUAL doubles sparsemem speed) Christoph Lameter
2007-04-07 22:06 ` Christoph Lameter
2007-04-07 22:18 ` Andi Kleen
2007-04-07 22:18 ` Andi Kleen
2007-04-09 16:40 ` William Lee Irwin III
2007-04-09 16:40 ` William Lee Irwin III
2007-04-09 17:16 ` Christoph Lameter
2007-04-09 17:16 ` Christoph Lameter
2007-04-09 18:20 ` William Lee Irwin III
2007-04-09 18:20 ` William Lee Irwin III
2007-04-02 21:08 ` [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL Dave Hansen
2007-04-02 21:08 ` Dave Hansen
2007-04-02 21:28 ` Christoph Lameter
2007-04-02 21:28 ` Christoph Lameter
2007-04-02 21:43 ` Martin Bligh
2007-04-02 21:43 ` Martin Bligh
2007-04-02 21:56 ` Dave Hansen
2007-04-02 21:56 ` Dave Hansen
2007-04-02 22:29 ` Christoph Lameter
2007-04-02 22:29 ` Christoph Lameter
2007-04-02 22:31 ` Andi Kleen
2007-04-02 22:31 ` Andi Kleen
2007-04-02 22:37 ` Christoph Lameter
2007-04-02 22:37 ` Christoph Lameter
2007-04-02 22:41 ` Martin Bligh
2007-04-02 22:41 ` Martin Bligh
2007-04-02 22:49 ` Christoph Lameter
2007-04-02 22:49 ` Christoph Lameter
2007-04-02 22:52 ` Martin Bligh
2007-04-02 22:52 ` Martin Bligh
2007-04-05 12:07 ` Andy Whitcroft
2007-04-05 12:07 ` Andy Whitcroft
2007-04-04 21:27 ` Bob Picco
2007-04-04 21:27 ` Bob Picco
2007-04-04 22:38 ` Christoph Lameter
2007-04-04 22:38 ` Christoph Lameter
2007-04-02 23:03 ` Bjorn Helgaas
2007-04-02 23:03 ` Bjorn Helgaas
2007-04-02 15:44 ` Christoph Lameter
2007-04-02 15:44 ` Christoph Lameter
2007-04-02 16:18 ` Christoph Lameter
2007-04-02 16:18 ` Christoph Lameter
2007-04-02 20:50 ` [PATCH 1/2] Generic Virtual Memmap suport for SPARSEMEM Dave Hansen
2007-04-02 20:50 ` Dave Hansen
2007-04-02 21:00 ` Christoph Lameter
2007-04-02 21:00 ` Christoph Lameter
2007-04-02 21:22 ` Dave Hansen [this message]
2007-04-02 21:22 ` Dave Hansen
2007-04-02 21:31 ` Christoph Lameter
2007-04-02 21:31 ` Christoph Lameter
2007-04-02 21:42 ` Dave Hansen
2007-04-02 21:42 ` Dave Hansen
2007-04-02 21:53 ` Christoph Lameter
2007-04-02 21:53 ` Christoph Lameter
2007-04-02 22:05 ` Dave Hansen
2007-04-02 22:05 ` Dave Hansen
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=1175548924.22373.109.camel@localhost.localdomain \
--to=hansendc@us.ibm.com \
--cc=ak@suse.de \
--cc=clameter@sgi.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@google.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.