From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [REPOST PATCH 3/4] slab: introduce byte sized index for the freelist of a slab
Date: Tue, 10 Sep 2013 14:43:42 +0900 [thread overview]
Message-ID: <20130910054342.GB24602@lge.com> (raw)
In-Reply-To: <00000141032dea11-c5aa9c77-b2f2-4cab-b7a0-d37665a6cec8-000000@email.amazonses.com>
On Mon, Sep 09, 2013 at 02:44:03PM +0000, Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Joonsoo Kim wrote:
>
> > 32 byte is not minimum object size, minimum *kmalloc* object size
> > in default configuration. There are some slabs that their object size is
> > less than 32 byte. If we have a 8 byte sized kmem_cache, it has 512 objects
> > in 4K page.
>
> As far as I can recall only SLUB supports 8 byte objects. SLABs mininum
> has always been 32 bytes.
No.
There are many slabs that their object size are less than 32 byte.
And I can also create a 8 byte sized slab in my kernel with SLAB.
js1304@js1304-P5Q-DELUXE:~/Projects/remote_git/linux$ sudo cat /proc/slabinfo | awk '{if($4 < 32) print $0}'
slabinfo - version: 2.1
ecryptfs_file_cache 0 0 16 240 1 : tunables 120 60 8 : slabdata 0 0 0
jbd2_revoke_table_s 2 240 16 240 1 : tunables 120 60 8 : slabdata 1 1 0
journal_handle 0 0 24 163 1 : tunables 120 60 8 : slabdata 0 0 0
revoke_table 0 0 16 240 1 : tunables 120 60 8 : slabdata 0 0 0
scsi_data_buffer 0 0 24 163 1 : tunables 120 60 8 : slabdata 0 0 0
fsnotify_event_holder 0 0 24 163 1 : tunables 120 60 8 : slabdata 0 0 0
numa_policy 3 163 24 163 1 : tunables 120 60 8 : slabdata 1 1 0
>
> > Moreover, we can configure slab_max_order in boot time so that we can't know
> > how many object are in a certain slab in compile time. Therefore we can't
> > decide the size of the index in compile time.
>
> You can ignore the slab_max_order if necessary.
>
> > I think that byte and short int sized index support would be enough, but
> > it should be determined at runtime.
>
> On x86 f.e. it would add useless branching. The branches are never taken.
> You only need these if you do bad things to the system like requiring
> large contiguous allocs.
As I said before, since there is a possibility that some runtime loaded modules
use a 8 byte sized slab, we can't determine index size in compile time. Otherwise
we should always use short int sized index and I think that it is worse than
adding a branch.
Thanks.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [REPOST PATCH 3/4] slab: introduce byte sized index for the freelist of a slab
Date: Tue, 10 Sep 2013 14:43:42 +0900 [thread overview]
Message-ID: <20130910054342.GB24602@lge.com> (raw)
In-Reply-To: <00000141032dea11-c5aa9c77-b2f2-4cab-b7a0-d37665a6cec8-000000@email.amazonses.com>
On Mon, Sep 09, 2013 at 02:44:03PM +0000, Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Joonsoo Kim wrote:
>
> > 32 byte is not minimum object size, minimum *kmalloc* object size
> > in default configuration. There are some slabs that their object size is
> > less than 32 byte. If we have a 8 byte sized kmem_cache, it has 512 objects
> > in 4K page.
>
> As far as I can recall only SLUB supports 8 byte objects. SLABs mininum
> has always been 32 bytes.
No.
There are many slabs that their object size are less than 32 byte.
And I can also create a 8 byte sized slab in my kernel with SLAB.
js1304@js1304-P5Q-DELUXE:~/Projects/remote_git/linux$ sudo cat /proc/slabinfo | awk '{if($4 < 32) print $0}'
slabinfo - version: 2.1
ecryptfs_file_cache 0 0 16 240 1 : tunables 120 60 8 : slabdata 0 0 0
jbd2_revoke_table_s 2 240 16 240 1 : tunables 120 60 8 : slabdata 1 1 0
journal_handle 0 0 24 163 1 : tunables 120 60 8 : slabdata 0 0 0
revoke_table 0 0 16 240 1 : tunables 120 60 8 : slabdata 0 0 0
scsi_data_buffer 0 0 24 163 1 : tunables 120 60 8 : slabdata 0 0 0
fsnotify_event_holder 0 0 24 163 1 : tunables 120 60 8 : slabdata 0 0 0
numa_policy 3 163 24 163 1 : tunables 120 60 8 : slabdata 1 1 0
>
> > Moreover, we can configure slab_max_order in boot time so that we can't know
> > how many object are in a certain slab in compile time. Therefore we can't
> > decide the size of the index in compile time.
>
> You can ignore the slab_max_order if necessary.
>
> > I think that byte and short int sized index support would be enough, but
> > it should be determined at runtime.
>
> On x86 f.e. it would add useless branching. The branches are never taken.
> You only need these if you do bad things to the system like requiring
> large contiguous allocs.
As I said before, since there is a possibility that some runtime loaded modules
use a 8 byte sized slab, we can't determine index size in compile time. Otherwise
we should always use short int sized index and I think that it is worse than
adding a branch.
Thanks.
next prev parent reply other threads:[~2013-09-10 5:43 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 5:57 [REPOST PATCH 0/4] slab: implement byte sized indexes for the freelist of a slab Joonsoo Kim
2013-09-06 5:57 ` Joonsoo Kim
2013-09-06 5:57 ` [REPOST PATCH 1/4] slab: factor out calculate nr objects in cache_estimate Joonsoo Kim
2013-09-06 5:57 ` Joonsoo Kim
2013-09-06 15:48 ` Christoph Lameter
2013-09-06 15:48 ` Christoph Lameter
2013-09-09 4:32 ` Joonsoo Kim
2013-09-09 4:32 ` Joonsoo Kim
2013-09-06 5:57 ` [REPOST PATCH 2/4] slab: introduce helper functions to get/set free object Joonsoo Kim
2013-09-06 5:57 ` Joonsoo Kim
2013-09-06 15:49 ` Christoph Lameter
2013-09-06 15:49 ` Christoph Lameter
2013-09-06 5:57 ` [REPOST PATCH 3/4] slab: introduce byte sized index for the freelist of a slab Joonsoo Kim
2013-09-06 5:57 ` Joonsoo Kim
2013-09-06 15:58 ` Christoph Lameter
2013-09-06 15:58 ` Christoph Lameter
2013-09-09 4:32 ` Joonsoo Kim
2013-09-09 4:32 ` Joonsoo Kim
2013-09-09 14:44 ` Christoph Lameter
2013-09-09 14:44 ` Christoph Lameter
2013-09-10 5:43 ` Joonsoo Kim [this message]
2013-09-10 5:43 ` Joonsoo Kim
2013-09-10 21:25 ` Christoph Lameter
2013-09-10 21:25 ` Christoph Lameter
2013-09-11 1:04 ` Joonsoo Kim
2013-09-11 1:04 ` Joonsoo Kim
2013-09-11 14:22 ` Christoph Lameter
2013-09-11 14:22 ` Christoph Lameter
2013-09-12 6:52 ` Joonsoo Kim
2013-09-12 6:52 ` Joonsoo Kim
2013-09-06 5:57 ` [REPOST PATCH 4/4] slab: make more slab management structure off the slab Joonsoo Kim
2013-09-06 5:57 ` Joonsoo Kim
2013-09-06 15:59 ` Christoph Lameter
2013-09-06 15:59 ` Christoph 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=20130910054342.GB24602@lge.com \
--to=iamjoonsoo.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 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.