linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Christoph Lameter <cl@linux.com>,
	Jesper Dangaard Brouer <jbrouer@redhat.com>
Cc: lsf@lists.linux-foundation.org, linux-mm <linux-mm@kvack.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	js1304@gmail.com, lsf-pc@lists.linux-foundation.org
Subject: Re: [LSF/MM TOPIC] Ideas for SLUB allocator
Date: Tue, 12 Apr 2016 14:13:48 -0400	[thread overview]
Message-ID: <1460484828.7134.4.camel@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1604121057490.14315@east.gentwo.org>

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On Tue, 2016-04-12 at 11:01 -0500, Christoph Lameter wrote:
> On Tue, 12 Apr 2016, Jesper Dangaard Brouer wrote:
> 
> > I have some ideas for improving SLUB allocator further, after my
> > work
> > on implementing the slab bulk APIs.  Maybe you can give me a small
> > slot, I only have 7 guidance slides.  Or else I hope we/I can talk
> > about these ideas in a hallway track with Christoph and others
> > involved
> > in slab development...
> 
> I will be there.
> 
> > I've already published the preliminary slides here:
> >  http://people.netfilter.org/hawk/presentations/MM-summit2016/slab_
> > mm_summit2016.odp
> 
> Re Autotuning: SLUB obj per page:
> 	SLUB can combine pages of different orders in a slab cache so
> this would
> 	be possible.
> 
> per CPU freelist per page:
> 	Could we drop the per cpu partial lists if this works?
> 
> Clearing memory:
> 	Could exploit the fact that the page is zero on alloc and also
> zap
> 	when no object in the page is in use?

Between the SLUB things both of you want to
discuss, do you think one 30 minute slot will
be enough to start with, or should we schedule
a whole hour?

We have some free slots left on the second day,
where discussions can overflow if necessary.

-- 
All rights reversed

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-04-12 18:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-12 10:02 [LSF/MM TOPIC] Ideas for SLUB allocator Jesper Dangaard Brouer
2016-04-12 13:37 ` [Lsf] " Matthew Wilcox
2016-04-12 15:03   ` Jesper Dangaard Brouer
2016-04-12 16:01 ` Christoph Lameter
2016-04-12 18:13   ` Rik van Riel [this message]
2016-04-12 21:14     ` [Lsf] " Jesper Dangaard Brouer

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=1460484828.7134.4.camel@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jbrouer@redhat.com \
    --cc=js1304@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=lsf@lists.linux-foundation.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.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 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).