linux-kernel - Re: [patch 21/21] slab defrag: Obsolete SLAB

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]

Date:	Wed, 14 May 2008 16:54:55 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Christoph Lameter <clameter@....com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Mel Gorman <mel@...net.ie>, Matthew Wilcox <matthew@....cx>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
Subject: Re: [patch 21/21] slab defrag: Obsolete SLAB


On Wed, 2008-05-14 at 14:26 -0700, Christoph Lameter wrote:
> > So far this is a bunch of hand-waving but I think this ends up
> basically
> > being an anti-magazine. A magazine puts a per-cpu queue on the alloc
> > side which costs on both the alloc and free side, regardless of whether
> > the workload demands it. This puts a per-cpu queue on the free side that
> > we can bypass in the cache-friendly case. I think that's a step in the
> > right direction.
> 
> I think if you want queues for an SMP only system, do not care too much 
> about memory use, dont do any frequent allocations on multicore systems 
> and can tolerate the hiccups because your application does not care (most 
> enterprise apps are constructed that way) or if you are running benchmarks 
> that only access a limited dataset that fits into SLABs queues amd 
> avoid touch the contenst of objects then the SLAB concept is the right way 
> to go.

> If we would strip the NUMA stuff out and make it an SMP only allocator for 
> enterprise apps then the code may become much smaller and simpler. I guess 
> Arjan suggested something similar in the past. But that would result in 
> SLAB no longer being a general allocator.

What does this have to do with anything? I'm not talking about going
back to SLAB. I'm talking about plugging the use cases where SLUB
currently loses to SLAB. That's what has to happen before SLAB can be
obsoleted.

I'll certainly grant you that queueing might not break even.

-- 
Mathematics is the supreme nostalgia of our time.

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