Re: [RFC V2 SLEB 00/14] The Enhanced(hopefully) Slab Allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 25, 2010 at 09:13:37AM -0500, Christoph Lameter wrote:
> On Tue, 25 May 2010, Nick Piggin wrote:
> 
> > On Mon, May 24, 2010 at 10:06:08AM -0500, Christoph Lameter wrote:
> > > On Mon, 24 May 2010, Nick Piggin wrote:
> > >
> > > > Well I'm glad you've conceded that queues are useful for high
> > > > performance computing, and that higher order allocations are not
> > > > a free and unlimited resource.
> > >
> > > Ahem. I have never made any such claim and would never make them. And
> > > "conceding" something ???
> >
> > Well, you were quite vocal about the subject.
> 
> I was always vocal about the huge amounts of queues and the complexity
> coming with alien caches etc. The alien caches were introduced against my
> objections on the development team that did the NUMA slab. But even SLUB
> has "queues" as many have repeatedly pointed out. The queuing is
> different though in order to minimize excessive NUMA queueing. IMHO the
> NUMA design of SLAB has fundamental problems because it implements its own
> "NUMAness" aside from the page allocator.

And by the way I disagreed completely that this is a problem. And you
never demonstrated that it is a problem.

It's totally unproductive to say things like it implements its own
"NUMAness" aside from the page allocator. I can say SLUB implements its
own "numaness" because it is checking for objects matching NUMA
requirements too.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]