linux-kernel - Re: [PATCH RFC 1/3] slub: keep full slabs on list for per memcg caches

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:	Thu, 15 May 2014 10:15:10 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Vladimir Davydov <vdavydov@...allels.com>
cc:	hannes@...xchg.org, mhocko@...e.cz, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH RFC 1/3] slub: keep full slabs on list for per memcg
 caches

On Thu, 15 May 2014, Vladimir Davydov wrote:

> > That will significantly impact the fastpaths for alloc and free.
> >
> > Also a pretty significant change the logic of the fastpaths since they
> > were not designed to handle the full lists. In debug mode all operations
> > were only performed by the slow paths and only the slow paths so far
> > supported tracking full slabs.
>
> That's the minimal price we have to pay for slab re-parenting, because
> w/o it we won't be able to look up for all slabs of a particular per
> memcg cache. The question is, can it be tolerated or I'd better try some
> other way?

AFACIT these modifications all together will have a significant impact on
performance.

You could avoid the refcounting on free relying on the atomic nature of
cmpxchg operations. If you zap the per cpu slab then the fast path will be
forced to fall back to the slowpaths where you could do what you need to
do.

There is no tracking of full slabs without adding much more logic to the
fastpath. You could force any operation that affects tne full list into
the slow path. But that also would have an impact.

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