From: Mikulas Patocka <mpatocka@redhat.com>
To: Christopher Lameter <cl@linux.com>
Cc: Mike Snitzer <snitzer@redhat.com>,
Vlastimil Babka <vbabka@suse.cz>,
Matthew Wilcox <willy@infradead.org>,
Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, dm-devel@redhat.com,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE
Date: Tue, 17 Apr 2018 15:06:24 -0400 (EDT) [thread overview]
Message-ID: <alpine.LRH.2.02.1804171454020.26973@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1804170940340.17557@nuc-kabylake>
On Tue, 17 Apr 2018, Christopher Lameter wrote:
> On Mon, 16 Apr 2018, Mikulas Patocka wrote:
>
> > This patch introduces a flag SLAB_MINIMIZE_WASTE for slab and slub. This
> > flag causes allocation of larger slab caches in order to minimize wasted
> > space.
> >
> > This is needed because we want to use dm-bufio for deduplication index and
> > there are existing installations with non-power-of-two block sizes (such
> > as 640KB). The performance of the whole solution depends on efficient
> > memory use, so we must waste as little memory as possible.
>
> Hmmm. Can we come up with a generic solution instead?
>
> This may mean relaxing the enforcement of the allocation max order a bit
> so that we can get dense allocation through higher order allocs.
>
> But then higher order allocs are generally seen as problematic.
>
> Note that SLUB will fall back to smallest order already if a failure
> occurs so increasing slub_max_order may not be that much of an issue.
>
> Maybe drop the max order limit completely and use MAX_ORDER instead? That
> means that callers need to be able to tolerate failures.
I can make a slub-only patch with no extra flag (on a freshly booted
system it increases only the order of caches "TCPv6" and "sighand_cache"
by one - so it should not have unexpected effects):
Doing a generic solution for slab would be more comlpicated because slab
assumes that all slabs have the same order, so it can't fall-back to
lower-order allocations.
From: Mikulas Patocka <mpatocka@redhat.com>
Subject: [PATCH] slub: minimize wasted space
When object size is greater than slub_max_order, the slub subsystem rounds
up the size to the next power of two. This causes a lot of wasted space -
i.e. 640KB block consumes 1MB of memory.
This patch makes the slub subsystem increase the order if it is benefical.
The order is increased as long as it reduces wasted space. There is cutoff
at 32 objects per slab.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
mm/slub.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2018-04-17 19:59:49.000000000 +0200
+++ linux-2.6/mm/slub.c 2018-04-17 20:58:23.000000000 +0200
@@ -3252,6 +3252,7 @@ static inline unsigned int slab_order(un
static inline int calculate_order(unsigned int size, unsigned int reserved)
{
unsigned int order;
+ unsigned int test_order;
unsigned int min_objects;
unsigned int max_objects;
@@ -3277,7 +3278,7 @@ static inline int calculate_order(unsign
order = slab_order(size, min_objects,
slub_max_order, fraction, reserved);
if (order <= slub_max_order)
- return order;
+ goto ret_order;
fraction /= 2;
}
min_objects--;
@@ -3289,15 +3290,25 @@ static inline int calculate_order(unsign
*/
order = slab_order(size, 1, slub_max_order, 1, reserved);
if (order <= slub_max_order)
- return order;
+ goto ret_order;
/*
* Doh this slab cannot be placed using slub_max_order.
*/
order = slab_order(size, 1, MAX_ORDER, 1, reserved);
- if (order < MAX_ORDER)
- return order;
- return -ENOSYS;
+ if (order >= MAX_ORDER)
+ return -ENOSYS;
+
+ret_order:
+ for (test_order = order + 1; test_order < MAX_ORDER; test_order++) {
+ unsigned long order_objects = ((PAGE_SIZE << order) - reserved) / size;
+ unsigned long test_order_objects = ((PAGE_SIZE << test_order) - reserved) / size;
+ if (test_order_objects > min(32, MAX_OBJS_PER_PAGE))
+ break;
+ if (test_order_objects > order_objects << (test_order - order))
+ order = test_order;
+ }
+ return order;
}
static void
next prev parent reply other threads:[~2018-04-17 19:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LRH.2.02.1803201740280.21066@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <alpine.DEB.2.20.1803211024220.2175@nuc-kabylake>
[not found] ` <alpine.LRH.2.02.1803211153320.16017@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <alpine.DEB.2.20.1803211226350.3174@nuc-kabylake>
[not found] ` <alpine.LRH.2.02.1803211425330.26409@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <20c58a03-90a8-7e75-5fc7-856facfb6c8a@suse.cz>
[not found] ` <20180413151019.GA5660@redhat.com>
[not found] ` <ee8807ff-d650-0064-70bf-e1d77fa61f5c@suse.cz>
[not found] ` <20180416142703.GA22422@redhat.com>
[not found] ` <alpine.LRH.2.02.1804161031300.24222@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <20180416144638.GA22484@redhat.com>
2018-04-16 19:32 ` [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE Mikulas Patocka
2018-04-17 14:45 ` Christopher Lameter
2018-04-17 16:16 ` Vlastimil Babka
2018-04-17 16:38 ` Christopher Lameter
2018-04-17 19:09 ` Mikulas Patocka
2018-04-17 17:26 ` Mikulas Patocka
2018-04-17 19:13 ` Vlastimil Babka
2018-04-17 19:06 ` Mikulas Patocka [this message]
2018-04-18 14:55 ` Christopher Lameter
2018-04-25 21:04 ` Mikulas Patocka
2018-04-25 23:24 ` Mikulas Patocka
2018-04-26 19:01 ` Christopher Lameter
2018-04-26 21:09 ` Mikulas Patocka
2018-04-27 16:41 ` Christopher Lameter
2018-04-27 19:19 ` Mikulas Patocka
2018-06-13 17:01 ` Mikulas Patocka
2018-06-13 18:16 ` Christoph Hellwig
2018-06-13 18:53 ` Mikulas Patocka
2018-04-26 18:51 ` Christopher Lameter
[not found] ` <alpine.LRH.2.02.1804161054410.17807@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <alpine.DEB.2.20.1804161018030.9397@nuc-kabylake>
[not found] ` <alpine.LRH.2.02.1804161123400.17807@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <alpine.DEB.2.20.1804161043430.9622@nuc-kabylake>
[not found] ` <alpine.LRH.2.02.1804161532480.19492@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <b0e6ccf6-06ce-e50b-840e-c8d3072382fd@suse.cz>
2018-04-16 21:01 ` Mikulas Patocka
2018-04-17 14:40 ` Christopher Lameter
2018-04-17 18:53 ` Mikulas Patocka
2018-04-17 21:42 ` Christopher Lameter
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=alpine.LRH.2.02.1804171454020.26973@file01.intranet.prod.int.rdu2.redhat.com \
--to=mpatocka@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dm-devel@redhat.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=snitzer@redhat.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).