On Tue, 2012-10-16 at 15:27 -0300, Ezequiel Garcia wrote:
> Yes, we have some numbers:
>
> http://elinux.org/Kernel_dynamic_memory_analysis#Kmalloc_objects
>
> Are they too informal? I can add some details...
>
> They've been measured on a **very** minimal setup, almost every option
> is stripp
On Thu, 11 Oct 2012, Ezequiel Garcia wrote:
> * Is SLAB a proper choice? or is it just historical an never been
> re-evaluated?
> * Does the average embedded guy knows which allocator to choose
> and what's the impact on his platform?
My current ideas on this subject matter is to get to a poin
On Tue, 16 Oct 2012, Ezequiel Garcia wrote:
> It might be worth reminding that very small systems can use SLOB
> allocator, which does not suffer from this kind of fragmentation.
Well, I have never seen non experimental systems that use SLOB. Others
have claimed they exist.
On Mon, 15 Oct 2012, David Rientjes wrote:
> This type of workload that really exhibits the problem with remote freeing
> would suggest that the design of slub itself is the problem here.
There is a tradeoff here between spatial data locality and temporal
locality. Slub always frees to the queue
On Tue, Oct 16, 2012 at 3:44 PM, Tim Bird wrote:
> On 10/16/2012 11:27 AM, Ezequiel Garcia wrote:
>> On Tue, Oct 16, 2012 at 3:07 PM, Tim Bird wrote:
>>> On 10/16/2012 05:56 AM, Eric Dumazet wrote:
On Tue, 2012-10-16 at 09:35 -0300, Ezequiel Garcia wrote:
> Now, returning to the fra
On 10/16/2012 11:27 AM, Ezequiel Garcia wrote:
> On Tue, Oct 16, 2012 at 3:07 PM, Tim Bird wrote:
>> On 10/16/2012 05:56 AM, Eric Dumazet wrote:
>>> On Tue, 2012-10-16 at 09:35 -0300, Ezequiel Garcia wrote:
>>>
Now, returning to the fragmentation. The problem with SLAB is that
its smalle
On Tue, Oct 16, 2012 at 3:07 PM, Tim Bird wrote:
> On 10/16/2012 05:56 AM, Eric Dumazet wrote:
>> On Tue, 2012-10-16 at 09:35 -0300, Ezequiel Garcia wrote:
>>
>>> Now, returning to the fragmentation. The problem with SLAB is that
>>> its smaller cache available for kmalloced objects is 32 bytes;
>
On 10/16/2012 07:35 AM, Wolfgang Denk wrote:
> Dear Constantine Shulyupin,
>
> In message
> you
> wrote:
>>
>> I have some questions and ideas about documentation in PDF format.
>> During embedded SW development I often work with documentation,
>> especially datasheets in PDF format. I have som
On Tue, Oct 16, 2012 at 3:07 PM, Tim Bird wrote:
> On 10/16/2012 05:56 AM, Eric Dumazet wrote:
>> On Tue, 2012-10-16 at 09:35 -0300, Ezequiel Garcia wrote:
>>
>>> Now, returning to the fragmentation. The problem with SLAB is that
>>> its smaller cache available for kmalloced objects is 32 bytes;
>
On 10/16/2012 05:56 AM, Eric Dumazet wrote:
> On Tue, 2012-10-16 at 09:35 -0300, Ezequiel Garcia wrote:
>
>> Now, returning to the fragmentation. The problem with SLAB is that
>> its smaller cache available for kmalloced objects is 32 bytes;
>> while SLUB allows 8, 16, 24 ...
>>
>> Perhaps adding
On Tue, 2012-10-16 at 09:35 -0300, Ezequiel Garcia wrote:
> Now, returning to the fragmentation. The problem with SLAB is that
> its smaller cache available for kmalloced objects is 32 bytes;
> while SLUB allows 8, 16, 24 ...
>
> Perhaps adding smaller caches to SLAB might make sense?
> Is there
On Tue, 2012-10-16 at 10:28 +0900, JoonSoo Kim wrote:
> Hello, Eric.
>
> 2012/10/14 Eric Dumazet :
> > SLUB was really bad in the common workload you describe (allocations
> > done by one cpu, freeing done by other cpus), because all kfree() hit
> > the slow path and cpus contend in __slab_free()
Hello, Eric.
2012/10/14 Eric Dumazet :
> SLUB was really bad in the common workload you describe (allocations
> done by one cpu, freeing done by other cpus), because all kfree() hit
> the slow path and cpus contend in __slab_free() in the loop guarded by
> cmpxchg_double_slab(). SLAB has a cache f
On Sat, 13 Oct 2012, Ezequiel Garcia wrote:
> But SLAB suffers from a lot more internal fragmentation than SLUB,
> which I guess is a known fact. So memory-constrained devices
> would waste more memory by using SLAB.
Even with slub's per-cpu partial lists?
On Sat, 13 Oct 2012, David Rientjes wrote:
> This was in August when preparing for LinuxCon, I tested netperf TCP_RR on
> two 64GB machines (one client, one server), four nodes each, with thread
> counts in multiples of the number of cores. SLUB does a comparable job,
> but once we have the th
On Sat, 2012-10-13 at 02:51 -0700, David Rientjes wrote:
> On Thu, 11 Oct 2012, Andi Kleen wrote:
>
> > When did you last test? Our regressions had disappeared a few kernels
> > ago.
> >
>
> This was in August when preparing for LinuxCon, I tested netperf TCP_RR on
> two 64GB machines (one clie
On Fri, 12 Oct 2012, Ezequiel Garcia wrote:
> >> SLUB is a non-starter for us and incurs a >10% performance degradation in
> >> netperf TCP_RR.
> >
>
> Where are you seeing that?
>
In my benchmarking results.
> Notice that many defconfigs are for embedded devices,
> and many of them say "use S
On Thu, 11 Oct 2012, Andi Kleen wrote:
> When did you last test? Our regressions had disappeared a few kernels
> ago.
>
This was in August when preparing for LinuxCon, I tested netperf TCP_RR on
two 64GB machines (one client, one server), four nodes each, with thread
counts in multiples of the
David Rientjes writes:
> On Thu, 11 Oct 2012, Andi Kleen wrote:
>
>> > While I've always thought SLUB was the default and recommended allocator,
>> > I'm surprise to find that it's not always the case:
>>
>> iirc the main performance reasons for slab over slub have mostly
>> disappeared, so in t
On Thu, 11 Oct 2012, Andi Kleen wrote:
> > While I've always thought SLUB was the default and recommended allocator,
> > I'm surprise to find that it's not always the case:
>
> iirc the main performance reasons for slab over slub have mostly
> disappeared, so in theory slab could be finally depre
Ezequiel Garcia writes:
> Hello,
>
> While I've always thought SLUB was the default and recommended allocator,
> I'm surprise to find that it's not always the case:
iirc the main performance reasons for slab over slub have mostly
disappeared, so in theory slab could be finally deprecated now.
-
Dear Constantine Shulyupin,
In message
you wrote:
>
> I have some questions and ideas about documentation in PDF format.
> During embedded SW development I often work with documentation,
> especially datasheets in PDF format. I have some issues with such
> documentation. It is not so easy to ma
On Tue, Oct 16, 2012 at 9:22 AM, Constantine Shulyupin
wrote:
> Hi,
>
> I have some questions and ideas about documentation in PDF format.
> During embedded SW development I often work with documentation,
> especially datasheets in PDF format. I have some issues with such
> documentation. It is no
Hi,
I have some questions and ideas about documentation in PDF format.
During embedded SW development I often work with documentation,
especially datasheets in PDF format. I have some issues with such
documentation. It is not so easy to manage a lot of PDF documents
sometimes with strange code in
David,
On Mon, Oct 15, 2012 at 9:46 PM, David Rientjes wrote:
> On Sat, 13 Oct 2012, Ezequiel Garcia wrote:
>
>> But SLAB suffers from a lot more internal fragmentation than SLUB,
>> which I guess is a known fact. So memory-constrained devices
>> would waste more memory by using SLAB.
>
> Even wi
25 matches
Mail list logo
