From: Vlastimil Babka <vbabka@suse.cz>
To: Baoquan He <bhe@redhat.com>
Cc: David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@linux.com>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Jay Patel <jaypatel@linux.ibm.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, patches@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] mm/slub: refactor calculate_order() and calc_slab_order()
Date: Fri, 22 Sep 2023 09:00:45 +0200 [thread overview]
Message-ID: <4662588e-fc8b-1854-57f8-d15e08a3c368@suse.cz> (raw)
In-Reply-To: <ZQUE0e4i8HrGUthB@MiWiFi-R3L-srv>
On 9/16/23 03:28, Baoquan He wrote:
> On 09/08/23 at 04:53pm, Vlastimil Babka wrote:
>> @@ -4152,7 +4147,7 @@ static inline int calculate_order(unsigned int size)
>> * order on systems that appear larger than they are, and too
>> * low order on systems that appear smaller than they are.
>> */
>> - nr_cpus = num_present_cpus();
>> + unsigned int nr_cpus = num_present_cpus();
>> if (nr_cpus <= 1)
>> nr_cpus = nr_cpu_ids;
>> min_objects = 4 * (fls(nr_cpus) + 1);
>
> A minor concern, should we change 'min_objects' to be a local static
> to avoid the "if (!min_objects) {" code block every time? It's deducing
> the value from nr_cpus, we may not need do the calculation each time.
Maybe, although it's not a hot path. But we should make sure the
num_present_cpus() cannot change. Could it be e.g. low (1) very early when
we bootstrap the initial caches, but then update and at least most of the
caches then reflect the real number of cpus? With a static we would create
everything with 1.
>> @@ -4160,6 +4155,10 @@ static inline int calculate_order(unsigned int size)
>> max_objects = order_objects(slub_max_order, size);
>> min_objects = min(min_objects, max_objects);
>>
>> + min_order = max(slub_min_order, (unsigned int)get_order(min_objects * size));
>> + if (order_objects(min_order, size) > MAX_OBJS_PER_PAGE)
>> + return get_order(size * MAX_OBJS_PER_PAGE) - 1;
>> +
>> /*
>> * Attempt to find best configuration for a slab. This works by first
>> * attempting to generate a layout with the best possible configuration and
>> @@ -4176,7 +4175,7 @@ static inline int calculate_order(unsigned int size)
>> * long as at least single object fits within slub_max_order.
>> */
>> for (unsigned int fraction = 16; fraction > 1; fraction /= 2) {
>> - order = calc_slab_order(size, min_objects, slub_max_order,
>> + order = calc_slab_order(size, min_order, slub_max_order,
>> fraction);
>> if (order <= slub_max_order)
>> return order;
>> --
>> 2.42.0
>>
>
next prev parent reply other threads:[~2023-09-22 7:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 14:53 [PATCH 0/4] SLUB: calculate_order() cleanups Vlastimil Babka
2023-09-08 14:53 ` [PATCH 1/4] mm/slub: simplify the last resort slab order calculation Vlastimil Babka
2023-09-19 7:56 ` Feng Tang
2023-09-20 6:38 ` Vlastimil Babka
2023-09-20 7:09 ` Feng Tang
2023-09-08 14:53 ` [PATCH 2/4] mm/slub: remove min_objects loop from calculate_order() Vlastimil Babka
2023-09-08 14:53 ` [PATCH 3/4] mm/slub: attempt to find layouts up to 1/2 waste in calculate_order() Vlastimil Babka
2023-09-20 13:11 ` Feng Tang
2023-09-08 14:53 ` [PATCH 4/4] mm/slub: refactor calculate_order() and calc_slab_order() Vlastimil Babka
2023-09-11 5:56 ` kernel test robot
2023-09-15 13:36 ` Vlastimil Babka
2023-09-16 1:28 ` Baoquan He
2023-09-22 7:00 ` Vlastimil Babka [this message]
2023-09-22 7:29 ` Baoquan He
2023-09-20 13:36 ` Feng Tang
2023-09-22 6:55 ` Vlastimil Babka
[not found] ` <5c933e2b06ab9090d9190bac41ebbc175b0a9357.camel@linux.ibm.com>
2023-10-02 12:38 ` [PATCH 0/4] SLUB: calculate_order() cleanups Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4662588e-fc8b-1854-57f8-d15e08a3c368@suse.cz \
--to=vbabka@suse.cz \
--cc=42.hyeyoo@gmail.com \
--cc=bhe@redhat.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jaypatel@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=patches@lists.linux.dev \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox