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

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

 



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.

 
> The "unqueueing" was the result of excessive queue handling in SLAB due and
> the higher order allocations are a natural move in HPC to gain performance.

This is the kind of handwavings that need to be put into a testable
form. I repeatedly asked you for examples of where the jitter is
excessive or where the TLB improvements help, but you never provided
any testable case. I'm not saying they don't exist, but we have to be
reational about this.

 
> > I hope we can move forward now with some objective, testable
> > comparisons and criteria for selecting one main slab allocator.
> 
> If can find criteria that are universally agreed upon then yes but that is
> doubtful.

I think we can agree that perfect is the enemy of good, and that no
allocator will do the perfect thing for everybody. I think we have to
come up with a way to a single allocator.

--
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]