Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <76c63237-c489-b942-bdd9-5720042f52a9@suse.cz>
Date:   Tue, 5 Apr 2022 12:04:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [PATCH v2 1/2] mm, slub: change percpu partial accounting from
 objects to pages
Content-Language: en-US
To:     Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc:     linux-mm@kvack.org, Christoph Lameter <cl@linux.com>,
        David Rientjes <rientjes@google.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Pekka Enberg <penberg@kernel.org>,
        Jann Horn <jannh@google.com>, linux-kernel@vger.kernel.org,
        Roman Gushchin <guro@fb.com>
References: <20211012134651.11258-1-vbabka@suse.cz>
 <Yja4AlOHkpcKLu59@ip-172-31-19-208.ap-northeast-1.compute.internal>
From:   Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <Yja4AlOHkpcKLu59@ip-172-31-19-208.ap-northeast-1.compute.internal>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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