linux-kernel - Re: [PATCH 1/2] Generic Virtual Memmap suport for SPARSEMEM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1175550151.22373.116.camel@localhost.localdomain>
Date:	Mon, 02 Apr 2007 14:42:31 -0700
From:	Dave Hansen <hansendc@...ibm.com>
To:	Christoph Lameter <clameter@....com>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	Martin Bligh <mbligh@...gle.com>, linux-mm@...ck.org,
	Andi Kleen <ak@...e.de>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [PATCH 1/2] Generic Virtual Memmap suport for SPARSEMEM

On Mon, 2007-04-02 at 14:31 -0700, Christoph Lameter wrote:
> On Mon, 2 Apr 2007, Dave Hansen wrote:
> 
> > > > 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?
> 
> The slab allocator purposes is to deliver small sub page sized chunks.
> The page allocator is there to allocate pages. Both are optimized for its 
> purpose.

I understand that, in general, but how does that optimization help,
here, exactly?  My argument is that if we use the slab, it means more
code sharing with existing code in sparse.c.  Other than ideology, what
practical reasons are there in this case that keep us from doing that
otherwise attractive code sharing.

> > > I just extended this in V2 to also work on IA64. Its pretty generic.
> > 
> > Can you extend it to work on ppc? ;)
> 
> I do not know enough about how ppc handles large pages.

I don't think the pagetable walks are generic enough to ever get used on
ppc, unless they start walking the Linux pagetables for the kernel
virtual address area.  I was trying to poke you into getting the
pagetable walks out of sparse.c. ;)

> > > > 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.
> 
> Well think about how to handle the case that the allocatiopn of a page 
> table page or a vmemmap block fails. Once we have that sorted out then we 
> can cleanup the higher layers.

I think it is best to just completely replace
sparse_early_mem_map_alloc() for the vmemmap case.  It really is a
completely different beast.  You'd never, for instance, have
alloc_remap() come into play.

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/