From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: linux-mm@kvack.org, Christoph Lameter <cl@linux.com>,
Vladimir Davydov <vdavydov@virtuozzo.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
brouer@redhat.com
Subject: Re: [PATCH 10/10] mm: new API kfree_bulk() for SLAB+SLUB allocators
Date: Fri, 8 Jan 2016 12:20:25 +0100 [thread overview]
Message-ID: <20160108122025.4605528c@redhat.com> (raw)
In-Reply-To: <20160108030348.GC14457@js1304-P5Q-DELUXE>
On Fri, 8 Jan 2016 12:03:48 +0900
Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> On Thu, Jan 07, 2016 at 03:04:23PM +0100, Jesper Dangaard Brouer wrote:
> > This patch introduce a new API call kfree_bulk() for bulk freeing
> > memory objects not bound to a single kmem_cache.
> >
> > Christoph pointed out that it is possible to implement freeing of
> > objects, without knowing the kmem_cache pointer as that information is
> > available from the object's page->slab_cache. Proposing to remove the
> > kmem_cache argument from the bulk free API.
> >
> > Jesper demonstrated that these extra steps per object comes at a
> > performance cost. It is only in the case CONFIG_MEMCG_KMEM is
> > compiled in and activated runtime that these steps are done anyhow.
> > The extra cost is most visible for SLAB allocator, because the SLUB
> > allocator does the page lookup (virt_to_head_page()) anyhow.
> >
> > Thus, the conclusion was to keep the kmem_cache free bulk API with a
> > kmem_cache pointer, but we can still implement a kfree_bulk() API
> > fairly easily. Simply by handling if kmem_cache_free_bulk() gets
> > called with a kmem_cache NULL pointer.
> >
> > This does increase the code size a bit, but implementing a separate
> > kfree_bulk() call would likely increase code size even more.
> >
> > Below benchmarks cost of alloc+free (obj size 256 bytes) on
> > CPU i7-4790K @ 4.00GHz, no PREEMPT and CONFIG_MEMCG_KMEM=y.
> >
> > Code size increase for SLAB:
> >
> > add/remove: 0/0 grow/shrink: 1/0 up/down: 74/0 (74)
> > function old new delta
> > kmem_cache_free_bulk 660 734 +74
> >
> > SLAB fastpath: 85 cycles(tsc) 21.468 ns (step:0)
> > sz - fallback - kmem_cache_free_bulk - kfree_bulk
> > 1 - 101 cycles 25.291 ns - 41 cycles 10.499 ns - 130 cycles 32.522 ns
>
> This looks experimental error. Why does kfree_bulk() takes more time
> than fallback?
This does look like an experimental error. Sometimes instabilities
occurs, when slab_caches gets merged, but I tried to counter that by
using boot param slab_nomerge.
In the case for SLAB kfree_bulk() single object, then it can be slower
than the fallback, because it will likely always hit a branch
mispredict for the kfree case (which is okay, as that is not the case
we optimize for, single obj free).
--
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>
next prev parent reply other threads:[~2016-01-08 11:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 14:03 [PATCH 00/10] MM: More bulk API work Jesper Dangaard Brouer
2016-01-07 14:03 ` [PATCH 01/10] slub: cleanup code for kmem cgroup support to kmem_cache_free_bulk Jesper Dangaard Brouer
2016-01-07 15:54 ` Christoph Lameter
2016-01-07 17:41 ` Jesper Dangaard Brouer
2016-01-08 2:58 ` Joonsoo Kim
2016-01-08 11:05 ` Jesper Dangaard Brouer
2016-01-07 14:03 ` [PATCH 02/10] mm/slab: move SLUB alloc hooks to common mm/slab.h Jesper Dangaard Brouer
2016-01-07 14:03 ` [PATCH 03/10] mm: fault-inject take over bootstrap kmem_cache check Jesper Dangaard Brouer
2016-01-07 14:03 ` [PATCH 04/10] slab: use slab_pre_alloc_hook in SLAB allocator shared with SLUB Jesper Dangaard Brouer
2016-01-08 3:05 ` Joonsoo Kim
2016-01-07 14:03 ` [PATCH 05/10] mm: kmemcheck skip object if slab allocation failed Jesper Dangaard Brouer
2016-01-07 14:04 ` [PATCH 06/10] slab: use slab_post_alloc_hook in SLAB allocator shared with SLUB Jesper Dangaard Brouer
2016-01-07 14:04 ` [PATCH 07/10] slab: implement bulk alloc in SLAB allocator Jesper Dangaard Brouer
2016-01-07 14:04 ` [PATCH 08/10] slab: avoid running debug SLAB code with IRQs disabled for alloc_bulk Jesper Dangaard Brouer
2016-01-07 14:04 ` [PATCH 09/10] slab: implement bulk free in SLAB allocator Jesper Dangaard Brouer
2016-01-07 14:04 ` [PATCH 10/10] mm: new API kfree_bulk() for SLAB+SLUB allocators Jesper Dangaard Brouer
2016-01-08 3:03 ` Joonsoo Kim
2016-01-08 11:20 ` Jesper Dangaard Brouer [this message]
2016-01-07 18:54 ` [PATCH 00/10] MM: More bulk API work Linus Torvalds
2016-01-12 15:13 ` [PATCH V2 00/11] " Jesper Dangaard Brouer
2016-01-12 15:13 ` [PATCH V2 01/11] slub: cleanup code for kmem cgroup support to kmem_cache_free_bulk Jesper Dangaard Brouer
2016-01-12 15:13 ` [PATCH V2 02/11] mm/slab: move SLUB alloc hooks to common mm/slab.h Jesper Dangaard Brouer
2016-01-12 15:14 ` [PATCH V2 03/11] mm: fault-inject take over bootstrap kmem_cache check Jesper Dangaard Brouer
2016-01-12 15:14 ` [PATCH V2 04/11] slab: use slab_pre_alloc_hook in SLAB allocator shared with SLUB Jesper Dangaard Brouer
2016-01-12 15:14 ` [PATCH V2 05/11] mm: kmemcheck skip object if slab allocation failed Jesper Dangaard Brouer
2016-01-12 15:14 ` [PATCH V2 06/11] slab: use slab_post_alloc_hook in SLAB allocator shared with SLUB Jesper Dangaard Brouer
2016-01-12 15:15 ` [PATCH V2 07/11] slab: implement bulk alloc in SLAB allocator Jesper Dangaard Brouer
2016-01-12 15:15 ` [PATCH V2 08/11] slab: avoid running debug SLAB code with IRQs disabled for alloc_bulk Jesper Dangaard Brouer
2016-01-12 15:15 ` [PATCH V2 09/11] slab: implement bulk free in SLAB allocator Jesper Dangaard Brouer
2016-01-12 15:16 ` [PATCH V2 10/11] mm: new API kfree_bulk() for SLAB+SLUB allocators Jesper Dangaard Brouer
2016-01-12 15:16 ` [PATCH V2 11/11] mm: fix some spelling 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=20160108122025.4605528c@redhat.com \
--to=brouer@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.org \
--cc=vdavydov@virtuozzo.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.