From: Christoph Lameter <cl@linux.com>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 1/3] slub: don't fail kmem_cache_shrink if slab placement optimization fails
Date: Tue, 27 Jan 2015 11:02:12 -0600 (CST) [thread overview]
Message-ID: <alpine.DEB.2.11.1501271100520.25124@gentwo.org> (raw)
In-Reply-To: <20150127125838.GD5165@esperanza>
On Tue, 27 Jan 2015, Vladimir Davydov wrote:
> May be, we could remove this allocation at all then? I mean, always
> distribute slabs among constant number of buckets, say 32, like this:
The point of the sorting is to have the slab pages that only have a few
objects available at the beginning of the list. Allocations can then
easily reduce the size of hte partial page list.
What you could do is simply put all slab pages with more than 32 objects
available at the end of the list.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux.com>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 1/3] slub: don't fail kmem_cache_shrink if slab placement optimization fails
Date: Tue, 27 Jan 2015 11:02:12 -0600 (CST) [thread overview]
Message-ID: <alpine.DEB.2.11.1501271100520.25124@gentwo.org> (raw)
In-Reply-To: <20150127125838.GD5165@esperanza>
On Tue, 27 Jan 2015, Vladimir Davydov wrote:
> May be, we could remove this allocation at all then? I mean, always
> distribute slabs among constant number of buckets, say 32, like this:
The point of the sorting is to have the slab pages that only have a few
objects available at the beginning of the list. Allocations can then
easily reduce the size of hte partial page list.
What you could do is simply put all slab pages with more than 32 objects
available at the end of the list.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-01-27 17:02 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 12:55 [PATCH -mm 0/3] slub: make dead caches discard free slabs immediately Vladimir Davydov
2015-01-26 12:55 ` Vladimir Davydov
2015-01-26 12:55 ` [PATCH -mm 1/3] slub: don't fail kmem_cache_shrink if slab placement optimization fails Vladimir Davydov
2015-01-26 12:55 ` Vladimir Davydov
2015-01-26 15:48 ` Christoph Lameter
2015-01-26 15:48 ` Christoph Lameter
2015-01-26 17:01 ` Vladimir Davydov
2015-01-26 17:01 ` Vladimir Davydov
2015-01-26 18:24 ` Christoph Lameter
2015-01-26 18:24 ` Christoph Lameter
2015-01-26 19:36 ` Vladimir Davydov
2015-01-26 19:36 ` Vladimir Davydov
2015-01-26 19:53 ` Christoph Lameter
2015-01-26 19:53 ` Christoph Lameter
2015-01-27 12:58 ` Vladimir Davydov
2015-01-27 12:58 ` Vladimir Davydov
2015-01-27 17:02 ` Christoph Lameter [this message]
2015-01-27 17:02 ` Christoph Lameter
2015-01-28 15:00 ` Vladimir Davydov
2015-01-28 15:00 ` Vladimir Davydov
2015-01-26 12:55 ` [PATCH -mm 2/3] slab: zap kmem_cache_shrink return value Vladimir Davydov
2015-01-26 12:55 ` Vladimir Davydov
2015-01-26 15:49 ` Christoph Lameter
2015-01-26 15:49 ` Christoph Lameter
2015-01-26 17:04 ` Vladimir Davydov
2015-01-26 17:04 ` Vladimir Davydov
2015-01-26 18:26 ` Christoph Lameter
2015-01-26 18:26 ` Christoph Lameter
2015-01-26 19:48 ` Vladimir Davydov
2015-01-26 19:48 ` Vladimir Davydov
2015-01-26 19:55 ` Christoph Lameter
2015-01-26 19:55 ` Christoph Lameter
2015-01-26 20:16 ` Vladimir Davydov
2015-01-26 20:16 ` Vladimir Davydov
2015-01-26 20:28 ` Christoph Lameter
2015-01-26 20:28 ` Christoph Lameter
2015-01-26 20:43 ` Vladimir Davydov
2015-01-26 20:43 ` Vladimir Davydov
2015-01-26 12:55 ` [PATCH -mm 3/3] slub: make dead caches discard free slabs immediately Vladimir Davydov
2015-01-26 12:55 ` Vladimir Davydov
2015-01-27 8:00 ` Joonsoo Kim
2015-01-27 8:00 ` Joonsoo Kim
2015-01-27 8:23 ` Vladimir Davydov
2015-01-27 8:23 ` Vladimir Davydov
2015-01-27 9:21 ` Joonsoo Kim
2015-01-27 9:21 ` Joonsoo Kim
2015-01-27 9:28 ` Vladimir Davydov
2015-01-27 9:28 ` Vladimir Davydov
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.DEB.2.11.1501271100520.25124@gentwo.org \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=vdavydov@parallels.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.