lkml.org 
[lkml]   [2011]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3] mm: make expand_downwards symmetrical to expand_upwards
From
Date
On Wed, 2011-04-20 at 09:50 -0500, Christoph Lameter wrote:
> On Wed, 20 Apr 2011, James Bottomley wrote:
>
> > 1. We can look at what imposing NUMA on the DISCONTIGMEM archs
> > would do ... the embedded ones are going to be hardest hit, but
> > if it's not too much extra code, it might be palatable.
> > 2. The other is that we can audit mm to look at all the node
> > assumptions in the non-numa case. My suspicion is that
> > accidentally or otherwise, it mostly works for the normal case,
> > so there might not be much needed to pull it back to working
> > properly for DISCONTIGMEM.
>
> The older code may work. SLAB f.e. does not call page_to_nid() in the
> !NUMA case but keeps special metadata structures around in each slab page
> that records the node used for allocation. The problem is with new code
> added/revised in the last 5 years or so that uses page_to_nid() and
> allocates only a single structure for !NUMA. There are also VM_BUG_ONs in
> the page allocator that should trigger if page_to_nid() returns strange
> values. I wonder why that never occurred.

Actually, I think slab got changed when discontigmem was added ...
that's why it all works OK.

> > 3. Finally we could look at deprecating DISCONTIGMEM in favour
> of > SPARSEMEM, but we'd still need to fix -stable for that case.
> > Especially as it will take time to convert all the architectures
>
> The fix needed is to mark DISCONTIGMEM without NUMA as broken for now. We
> need an audit of the core VM before removing that or making it contingent
> on the configurations of various VM subsystems.

Don't be stupid ... that would cause six architectures to get marked
broken.

> > I'm certainly with Matthew: DISCONTIGMEM is supposed to be a lightweight
> > framework which allows machines with split physical memory ranges to
> > work. That's a very common case nowadays. Numa is supposed to be a
> > heavyweight framework to preserve node locality for non-uniform memory
> > access boxes (which none of the DISCONTIGMEM && !NUMA systems are).
>
> Well yes but we have SPARSE for that today. DISCONTIG with multiple per
> pgdat structures in a !NUMA case is just weird and unexpected for many who
> have done VM coding in the last years.

Look, I'm not really interested in who understands what. The fact is we
have six architectures with the possibility for DISCONTIGMEM && !NUMA,
so that's the case we need to fix in -stable.

They oops with SLUB, as far as I can tell, there are still no oops
reports with SLAB. The simplest -stable fix seems to be to mark SLUB
broken on DISCONTIGMEM && !NUMA.

James




\
 
 \ /
  Last update: 2011-04-20 17:05    [W:0.106 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site