* [LSF/MM TOPIC] Ideas for SLUB allocator
@ 2016-04-12 10:02 Jesper Dangaard Brouer
2016-04-12 13:37 ` [Lsf] " Matthew Wilcox
2016-04-12 16:01 ` Christoph Lameter
0 siblings, 2 replies; 6+ messages in thread
From: Jesper Dangaard Brouer @ 2016-04-12 10:02 UTC (permalink / raw)
To: lsf, linux-mm, Rik van Riel, Christoph Lameter, Joonsoo Kim,
Pekka Enberg, David Rientjes, Andrew Morton, js1304
Cc: lsf-pc
Hi Rik,
I have another topic, which is very MM-specific.
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've already published the preliminary slides here:
http://people.netfilter.org/hawk/presentations/MM-summit2016/slab_mm_summit2016.odp
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Lsf] [LSF/MM TOPIC] Ideas for SLUB allocator
2016-04-12 10:02 [LSF/MM TOPIC] Ideas for SLUB allocator Jesper Dangaard Brouer
@ 2016-04-12 13:37 ` Matthew Wilcox
2016-04-12 15:03 ` Jesper Dangaard Brouer
2016-04-12 16:01 ` Christoph Lameter
1 sibling, 1 reply; 6+ messages in thread
From: Matthew Wilcox @ 2016-04-12 13:37 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: lsf, linux-mm, Rik van Riel, Christoph Lameter, Joonsoo Kim,
Pekka Enberg, David Rientjes, Andrew Morton, js1304, lsf-pc
On Tue, Apr 12, 2016 at 12:02:15PM +0200, Jesper Dangaard Brouer wrote:
> Hi Rik,
>
> I have another topic, which is very MM-specific.
>
> 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've already published the preliminary slides here:
> http://people.netfilter.org/hawk/presentations/MM-summit2016/slab_mm_summit2016.odp
The current bulk API returns the pointers in an array. What the
radix tree would like is the ability to bulk allocate from a slab and
chain the allocations through an offset. See __radix_tree_preload()
in lib/radix-tree.c. I don't know if this is a common thing to do
elsewhere in the kernel. Obviously, radix-tree could allocate the array
on the stack and set up the chain itself, but I would think it would be
just as easy for slab to do it itself and save the stack space.
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Lsf] [LSF/MM TOPIC] Ideas for SLUB allocator
2016-04-12 13:37 ` [Lsf] " Matthew Wilcox
@ 2016-04-12 15:03 ` Jesper Dangaard Brouer
0 siblings, 0 replies; 6+ messages in thread
From: Jesper Dangaard Brouer @ 2016-04-12 15:03 UTC (permalink / raw)
To: Matthew Wilcox
Cc: lsf, linux-mm, Rik van Riel, Christoph Lameter, Joonsoo Kim,
Pekka Enberg, David Rientjes, Andrew Morton, js1304, lsf-pc
On Tue, 12 Apr 2016 09:37:28 -0400
Matthew Wilcox <willy@linux.intel.com> wrote:
> On Tue, Apr 12, 2016 at 12:02:15PM +0200, Jesper Dangaard Brouer wrote:
> > Hi Rik,
> >
> > I have another topic, which is very MM-specific.
> >
> > 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've already published the preliminary slides here:
> > http://people.netfilter.org/hawk/presentations/MM-summit2016/slab_mm_summit2016.odp
>
> The current bulk API returns the pointers in an array. What the
> radix tree would like is the ability to bulk allocate from a slab and
> chain the allocations through an offset. See __radix_tree_preload()
> in lib/radix-tree.c. I don't know if this is a common thing to do
> elsewhere in the kernel. Obviously, radix-tree could allocate the array
> on the stack and set up the chain itself, but I would think it would be
> just as easy for slab to do it itself and save the stack space.
It does look like a good candidate for bulk alloc in __radix_tree_preload().
Especially because you have an annoying preempt_disable() and
preempt_enable() interaction loop, and reloading of this_cpu_ptr.
And RADIX_TREE_PRELOAD_SIZE==21 is not excessive alloc bulking.
Considering local_irq's are disabled during the bulk alloc.
The allocator is delivering "raw" memory, thus it does not know
anything about the callers data structure, and shouldn't. (I have
considered delivering bulk objects single linked via offset 0, as this
already happens internally in SLUB, but I decided against it)
Looking closer at your specific data structures, they are also a bit
complicated to deliver "linked" easily...
struct radix_tree_preload {
int nr;
/* nodes->private_data points to next preallocated node */
struct radix_tree_node *nodes;
};
struct radix_tree_node {
unsigned int path; /* Offset in parent & height from the bottom */
unsigned int count;
union {
struct {
/* Used when ascending tree */
struct radix_tree_node *parent;
/* For tree user */
void *private_data;
};
/* Used when freeing node */
struct rcu_head rcu_head;
};
/* For tree user */
struct list_head private_list;
void __rcu *slots[RADIX_TREE_MAP_SIZE];
unsigned long tags[RADIX_TREE_MAX_TAGS][RADIX_TREE_TAG_LONGS];
};
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LSF/MM TOPIC] Ideas for SLUB allocator
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 16:01 ` Christoph Lameter
2016-04-12 18:13 ` Rik van Riel
1 sibling, 1 reply; 6+ messages in thread
From: Christoph Lameter @ 2016-04-12 16:01 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: lsf, linux-mm, Rik van Riel, Joonsoo Kim, Pekka Enberg,
David Rientjes, Andrew Morton, js1304, lsf-pc
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?
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LSF/MM TOPIC] Ideas for SLUB allocator
2016-04-12 16:01 ` Christoph Lameter
@ 2016-04-12 18:13 ` Rik van Riel
2016-04-12 21:14 ` [Lsf] " Jesper Dangaard Brouer
0 siblings, 1 reply; 6+ messages in thread
From: Rik van Riel @ 2016-04-12 18:13 UTC (permalink / raw)
To: Christoph Lameter, Jesper Dangaard Brouer
Cc: lsf, linux-mm, Joonsoo Kim, Pekka Enberg, David Rientjes,
Andrew Morton, js1304, lsf-pc
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Lsf] [LSF/MM TOPIC] Ideas for SLUB allocator
2016-04-12 18:13 ` Rik van Riel
@ 2016-04-12 21:14 ` Jesper Dangaard Brouer
0 siblings, 0 replies; 6+ messages in thread
From: Jesper Dangaard Brouer @ 2016-04-12 21:14 UTC (permalink / raw)
To: Rik van Riel
Cc: brouer, Christoph Lameter, Pekka Enberg, js1304, lsf, linux-mm,
David Rientjes, Joonsoo Kim, lsf-pc, Andrew Morton
On Tue, 12 Apr 2016 14:13:48 -0400
Rik van Riel <riel@redhat.com> wrote:
> 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.
30 min slot is fine by me :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-04-12 21:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2016-04-12 21:14 ` [Lsf] " Jesper Dangaard Brouer
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.