LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Christopher Lameter <cl@linux.com>,
	Mike Snitzer <snitzer@redhat.com>,
	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: slab: introduce the flag SLAB_MINIMIZE_WASTE
Date: Mon, 16 Apr 2018 17:01:13 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1804161650170.7237@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <b0e6ccf6-06ce-e50b-840e-c8d3072382fd@suse.cz>



On Mon, 16 Apr 2018, Vlastimil Babka wrote:

> On 04/16/2018 09:36 PM, Mikulas Patocka wrote:
> 
> >>> I need to increase it just for dm-bufio slabs.
> >>
> >> If you do this then others will want the same...
> > 
> > If others need it, they can turn on the flag SLAB_MINIMIZE_WASTE too.
> 
> I think it should be possible without a new flag. The slub allocator
> could just balance priorities (performance vs memory efficiency) better.
> Currently I get the impression that "slub_max_order" is a performance
> tunable. Let's add another criteria for selecting an order, that would
> try to pick an order to minimize wasted space below e.g. 10% with some
> different kind of max order. Pick good defaults, add tunables if you must.
> 
> I mean, anyone who's creating a cache for 640KB objects most likely
> doesn't want to waste another 384KB by each such object. They shouldn't
> have to add a flag to let the slub allocator figure out that using 2MB
> pages is the right thing to do here.
> 
> Vlastimil

The problem is that higher-order allocations (larger than 32K) are 
unreliable. So, if you increase page order beyond that, the allocation may 
randomly fail.

dm-bufio deals gracefully with allocation failure, because it preallocates 
some buffers with vmalloc, but other subsystems may not deal with it and 
they cound return ENOMEM randomly or misbehave in other ways. So, the 
"SLAB_MINIMIZE_WASTE" flag is also saying that the allocation may fail and 
the caller is prepared to deal with it.

The slub subsystem does actual fallback to low-order when the allocation 
fails (it allows different order for each slab in the same cache), but 
slab doesn't fallback and you get NULL if higher-order allocation fails. 
So, SLAB_MINIMIZE_WASTE is needed for slab because it will just randomly 
fail with higher order.

Mikulas

  parent reply	other threads:[~2018-04-16 21:01 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] " 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
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 [this message]
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.1804161650170.7237@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 \
    --subject='Re: slab: introduce the flag SLAB_MINIMIZE_WASTE' \
    /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

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).