From: Tim Bird <tim.bird@am.sony.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ezequiel Garcia <elezegarcia@gmail.com>,
David Rientjes <rientjes@google.com>,
Andi Kleen <andi@firstfloor.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"celinux-dev@lists.celinuxforum.org"
<celinux-dev@lists.celinuxforum.org>
Subject: Re: [Q] Default SLAB allocator
Date: Wed, 17 Oct 2012 13:58:28 -0700 [thread overview]
Message-ID: <507F1BF4.6040209@am.sony.com> (raw)
In-Reply-To: <1350501217.26103.852.camel@edumazet-glaptop>
On 10/17/2012 12:13 PM, Eric Dumazet wrote:
> On Wed, 2012-10-17 at 11:45 -0700, Tim Bird wrote:
>
>> 8G is a small web server? The RAM budget for Linux on one of
>> Sony's cameras was 10M. We're not merely not in the same ballpark -
>> you're in a ballpark and I'm trimming bonsai trees... :-)
>>
>
> Even laptops in 2012 have +4GB of ram.
>
> (Maybe not Sony laptops, I have to double check ?)
>
> Yes, servers do have more ram than laptops.
>
> (Maybe not Sony servers, I have to double check ?)
I wouldn't know. I suspect they are running 4GB+
like everyone else.
>>> # grep Slab /proc/meminfo
>>> Slab: 351592 kB
>>>
>>> # egrep "kmalloc-32|kmalloc-16|kmalloc-8" /proc/slabinfo
>>> kmalloc-32 11332 12544 32 128 1 : tunables 0 0 0 : slabdata 98 98 0
>>> kmalloc-16 5888 5888 16 256 1 : tunables 0 0 0 : slabdata 23 23 0
>>> kmalloc-8 76563 82432 8 512 1 : tunables 0 0 0 : slabdata 161 161 0
>>>
>>> Really, some waste on these small objects is pure noise on SMP hosts.
>> In this example, it appears that if all kmalloc-8's were pushed into 32-byte slabs,
>> we'd lose about 1.8 meg due to pure slab overhead. This would not be noise
>> on my system.
> I said :
>
> <quote>
> I would remove small kmalloc-XX caches, as sharing a cache line
> is sometime dangerous for performance, because of false sharing.
>
> They make sense only for very small hosts
> </quote>
>
> I think your 10M cameras are very tiny hosts.
I agree. Actually, I'm currently doing research for
items with smaller memory footprints that this. My current
target is devices with 4M RAM and 8M NOR flash.
Undoubtedly this is different than what a lot of other
people are doing with Linux.
> Using SLUB on them might not be the best choice.
Indeed. :-)
I'm still interested in the dynamics of the slab sizes
and how it impacts performance, how much memory is wasted, etc.
I think there are a few "power-of-two-and-a-half" kmalloc
slabs (e.g. kmalloc-192). Are these configurable anywhere?
Anyway, I greatly appreciate the discussion.
> First time I ran linux, years ago, it was on 486SX machines with 8M of
> memory (or maybe less, I dont remember exactly). But I no longer use
> this class of machines with recent kernels.
I ran a web server on an 8M machine that had an uptime of over 2 years,
but that was in the mid-90's. Ahhh - those were the days...
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
--
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: Tim Bird <tim.bird@am.sony.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ezequiel Garcia <elezegarcia@gmail.com>,
David Rientjes <rientjes@google.com>,
Andi Kleen <andi@firstfloor.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"celinux-dev@lists.celinuxforum.org"
<celinux-dev@lists.celinuxforum.org>
Subject: Re: [Q] Default SLAB allocator
Date: Wed, 17 Oct 2012 13:58:28 -0700 [thread overview]
Message-ID: <507F1BF4.6040209@am.sony.com> (raw)
In-Reply-To: <1350501217.26103.852.camel@edumazet-glaptop>
On 10/17/2012 12:13 PM, Eric Dumazet wrote:
> On Wed, 2012-10-17 at 11:45 -0700, Tim Bird wrote:
>
>> 8G is a small web server? The RAM budget for Linux on one of
>> Sony's cameras was 10M. We're not merely not in the same ballpark -
>> you're in a ballpark and I'm trimming bonsai trees... :-)
>>
>
> Even laptops in 2012 have +4GB of ram.
>
> (Maybe not Sony laptops, I have to double check ?)
>
> Yes, servers do have more ram than laptops.
>
> (Maybe not Sony servers, I have to double check ?)
I wouldn't know. I suspect they are running 4GB+
like everyone else.
>>> # grep Slab /proc/meminfo
>>> Slab: 351592 kB
>>>
>>> # egrep "kmalloc-32|kmalloc-16|kmalloc-8" /proc/slabinfo
>>> kmalloc-32 11332 12544 32 128 1 : tunables 0 0 0 : slabdata 98 98 0
>>> kmalloc-16 5888 5888 16 256 1 : tunables 0 0 0 : slabdata 23 23 0
>>> kmalloc-8 76563 82432 8 512 1 : tunables 0 0 0 : slabdata 161 161 0
>>>
>>> Really, some waste on these small objects is pure noise on SMP hosts.
>> In this example, it appears that if all kmalloc-8's were pushed into 32-byte slabs,
>> we'd lose about 1.8 meg due to pure slab overhead. This would not be noise
>> on my system.
> I said :
>
> <quote>
> I would remove small kmalloc-XX caches, as sharing a cache line
> is sometime dangerous for performance, because of false sharing.
>
> They make sense only for very small hosts
> </quote>
>
> I think your 10M cameras are very tiny hosts.
I agree. Actually, I'm currently doing research for
items with smaller memory footprints that this. My current
target is devices with 4M RAM and 8M NOR flash.
Undoubtedly this is different than what a lot of other
people are doing with Linux.
> Using SLUB on them might not be the best choice.
Indeed. :-)
I'm still interested in the dynamics of the slab sizes
and how it impacts performance, how much memory is wasted, etc.
I think there are a few "power-of-two-and-a-half" kmalloc
slabs (e.g. kmalloc-192). Are these configurable anywhere?
Anyway, I greatly appreciate the discussion.
> First time I ran linux, years ago, it was on 486SX machines with 8M of
> memory (or maybe less, I dont remember exactly). But I no longer use
> this class of machines with recent kernels.
I ran a web server on an 8M machine that had an uptime of over 2 years,
but that was in the mid-90's. Ahhh - those were the days...
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
next prev parent reply other threads:[~2012-10-17 20:54 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-11 14:19 [Q] Default SLAB allocator Ezequiel Garcia
2012-10-11 14:19 ` Ezequiel Garcia
2012-10-11 22:42 ` Andi Kleen
2012-10-11 22:42 ` Andi Kleen
2012-10-11 22:59 ` David Rientjes
2012-10-11 22:59 ` David Rientjes
2012-10-11 23:10 ` Andi Kleen
2012-10-11 23:10 ` Andi Kleen
2012-10-12 12:07 ` Ezequiel Garcia
2012-10-12 12:07 ` Ezequiel Garcia
2012-10-13 9:54 ` David Rientjes
2012-10-13 9:54 ` David Rientjes
2012-10-13 12:44 ` Ezequiel Garcia
2012-10-13 12:44 ` Ezequiel Garcia
2012-10-16 0:46 ` David Rientjes
2012-10-16 0:46 ` David Rientjes
2012-10-16 12:35 ` Ezequiel Garcia
2012-10-16 12:35 ` Ezequiel Garcia
2012-10-16 12:56 ` Eric Dumazet
2012-10-16 12:56 ` Eric Dumazet
2012-10-16 18:07 ` Tim Bird
2012-10-16 18:07 ` Tim Bird
2012-10-16 18:27 ` Ezequiel Garcia
2012-10-16 18:27 ` Ezequiel Garcia
2012-10-16 18:44 ` Tim Bird
2012-10-16 18:44 ` Tim Bird
2012-10-16 18:49 ` Ezequiel Garcia
2012-10-16 18:49 ` Ezequiel Garcia
2012-10-16 19:16 ` Eric Dumazet
2012-10-16 19:16 ` Eric Dumazet
2012-10-17 18:45 ` Tim Bird
2012-10-17 18:45 ` Tim Bird
2012-10-17 19:13 ` Eric Dumazet
2012-10-17 19:13 ` Eric Dumazet
2012-10-17 19:20 ` Shentino
2012-10-17 19:20 ` Shentino
2012-10-17 20:33 ` Tim Bird
2012-10-17 20:33 ` Tim Bird
2012-10-18 0:46 ` Shentino
2012-10-18 0:46 ` Shentino
2012-10-17 20:58 ` Tim Bird [this message]
2012-10-17 20:58 ` Tim Bird
2012-10-17 21:05 ` Ezequiel Garcia
2012-10-17 21:05 ` Ezequiel Garcia
2012-10-16 18:36 ` Ezequiel Garcia
2012-10-16 18:36 ` Ezequiel Garcia
2012-10-16 18:54 ` Christoph Lameter
2012-10-16 18:54 ` Christoph Lameter
2012-10-13 9:51 ` David Rientjes
2012-10-13 9:51 ` David Rientjes
2012-10-13 15:10 ` Eric Dumazet
2012-10-13 15:10 ` Eric Dumazet
2012-10-16 1:28 ` JoonSoo Kim
2012-10-16 1:28 ` JoonSoo Kim
2012-10-16 7:23 ` Eric Dumazet
2012-10-16 7:23 ` Eric Dumazet
2012-10-19 0:03 ` JoonSoo Kim
2012-10-19 0:03 ` JoonSoo Kim
2012-10-19 7:01 ` Eric Dumazet
2012-10-19 7:01 ` Eric Dumazet
2012-10-16 0:45 ` David Rientjes
2012-10-16 0:45 ` David Rientjes
2012-10-16 18:53 ` Christoph Lameter
2012-10-16 18:53 ` Christoph Lameter
2012-10-16 19:02 ` Christoph Lameter
2012-10-16 19:02 ` 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=507F1BF4.6040209@am.sony.com \
--to=tim.bird@am.sony.com \
--cc=andi@firstfloor.org \
--cc=celinux-dev@lists.celinuxforum.org \
--cc=elezegarcia@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.