linux-kernel - RE: [PATCH 1/3] slub: set a criteria for slub node partial adding

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]

Message-ID: <alpine.DEB.2.00.1112140853540.12235@router.home>
Date:	Wed, 14 Dec 2011 08:59:24 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	"Alex,Shi" <alex.shi@...el.com>
cc:	Eric Dumazet <eric.dumazet@...il.com>,
	David Rientjes <rientjes@...gle.com>,
	"penberg@...nel.org" <penberg@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: RE: [PATCH 1/3] slub: set a criteria for slub node partial adding

On Wed, 14 Dec 2011, Alex,Shi wrote:

> > Please note that the COLD/HOT page concept is not very well used in
> > kernel, because its not really obvious that some decisions are always
> > good (or maybe this is not well known)
>
> Hope Christoph know everything of SLUB. :)

Well yes we have been back and forth on hot/cold page things repeatedly in
the page allocator as well. Caching is not always good. There are
particular loads that usually do very well with caching. Others do not.
Caching can cause useless processing and pollute caching. It is also a
cause for OS noise due to cache maintenance at random (for the app guys)
times where they do not want that to happen.

> > We should try to batch things a bit, instead of doing a very small unit
> > of work in slow path.
> >
> > We now have a very fast fastpath, but inefficient slow path.
> >
> > SLAB has a litle cache per cpu, we could add one to SLUB for freed
> > objects, not belonging to current slab. This could avoid all these
> > activate/deactivate overhead.
>
> Maybe worth to try or maybe Christoph had studied this?

Many people have done patchsets like this. There are various permutations
on SL?B (I dont remember them all SLEB, SLXB, SLQB etc) that have been
proposed over the years. Caches tend to grow and get rather numerous (see
SLAB) and the design of SLUB was to counter that. There is a reason it was
called SLUB. The U stands for Unqueued and was intended to avoid the
excessive caching problems that I ended up when reworking SLAB for NUMA
support.
--
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/