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:	Mon, 25 Aug 2014 08:13:58 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
	Tejun Heo <htejun@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] mm/slab: use percpu allocator for cpu cache

On Mon, 25 Aug 2014, Joonsoo Kim wrote:

> On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
> > On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> >
> > > So, this patch try to use percpu allocator in SLAB. This simplify
> > > initialization step in SLAB so that we could maintain SLAB code more
> > > easily.
> >
> > I thought about this a couple of times but the amount of memory used for
> > the per cpu arrays can be huge. In contrast to slub which needs just a
> > few pointers, slab requires one pointer per object that can be in the
> > local cache. CC Tj.
> >
> > Lets say we have 300 caches and we allow 1000 objects to be cached per
> > cpu. That is 300k pointers per cpu. 1.2M on 32 bit. 2.4M per cpu on
> > 64bit.
>
> Amount of memory we need to keep pointers for object is same in any case.

What case? SLUB uses a linked list and therefore does not have these
storage requirements.

> I know that percpu allocator occupy vmalloc space, so maybe we could
> exhaust vmalloc space on 32 bit. 64 bit has no problem on it.
> How many cores does largest 32 bit system have? Is it possible
> to exhaust vmalloc space if we use percpu allocator?

There were NUMA systems on x86 a while back (not sure if they still
exists) with 128 or so processors.

Some people boot 32 bit kernels on contemporary servers. The Intel ones
max out at 18 cores (36 hyperthreaded). I think they support up to 8
scokets. So 8 * 36?


Its different on other platforms with much higher numbers. Power can
easily go up to hundreds of hardware threads and SGI Altixes 7 yearsago
where at 8000 or so.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ