linux-kernel - Re: [PATCH v2 1/2] mm, slub: change percpu partial accounting from objects to pages

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] [day] [month] [year] [list]

Date:   Tue, 5 Apr 2022 12:04:18 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Hyeonggon Yoo <42.hyeyoo@...il.com>
Cc:     linux-mm@...ck.org, Christoph Lameter <cl@...ux.com>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Pekka Enberg <penberg@...nel.org>,
        Jann Horn <jannh@...gle.com>, linux-kernel@...r.kernel.org,
        Roman Gushchin <guro@...com>
Subject: Re: [PATCH v2 1/2] mm, slub: change percpu partial accounting from
 objects to pages

On 3/20/22 06:13, Hyeonggon Yoo wrote:
>> While this is no longer a problem in kmemcg context thanks to the accounting
>> rewrite in 5.9, the memory waste is still not ideal and it's questionable
>> whether it makes sense to perform free object count based control when object
>> counts can easily become so much inaccurate. So this patch converts the
>> accounting to be based on number of pages only (which is precise) and removes
>> the page->pobjects field completely. This is also ultimately simpler.
>> 
>> To retain the existing set_cpu_partial() heuristic, first calculate the target
>> number of objects as previously, but then convert it to target number of pages
>> by assuming the pages will be half-filled on average. This assumption might
>> obviously also be inaccurate in practice, but cannot degrade to actual number of
>> pages being equal to the target number of objects.
> 
> I have to agree that this half-filled assumption works pretty well and
> I believe the too-long-partial-list problem has gone. we're controlling
> its length clearly after this patch.
> 
> But my one concern here is that actual number of objects in
> percpu partial list can be decreased when we cannot allocate high order pages.
> 
> e.g.) oo_order(s->oo) is 3 and we can only allocate order-2 page,
> it can be shortened 2 times in worst case because the accounting logic
> assumes order of all slab in the percpu partial list is oo_order(s->oo).

That's true, but let's not forget the percpu partial lists are motivated by
peak performance in e.g. networking. Once we start having issues allocating
e.g. order-2 pages due to fragmentation, the system is probably far from
peak performance already, so this pessimism in slub partial lists is not the
main concern.

> I think using object based accounting, and assuming every slab is
> half-filled would be more consistent when the system is highly
> fragmented.

Based on reasoning above, I doubt it's worth the trouble.

Thanks.

> Thoughts?
>