Pekka J Enberg wrote:
Hi Christoph,
On Wed, 11 Jul 2007, Christoph Lameter wrote:
Of course you are the maintainer but you only authored a single patch
which was the original submission in all the time that SLOB was in the
tree. I keep having to clean up the allocator that has--according to
On Wed, 11 Jul 2007, Christoph Lameter wrote:
> But you did get 2.6.22 to compile it seems.
>
> Here is the fix against 2.6.22-rc6-mm1 again.
I didn't get so far to compile with SLUB. There's some UML architecture
problem and SLOB missing __kmalloc which UML also needs.
On Wed, 11 Jul 2007, Pekka J Enberg wrote:
> Hi Christoph,
>
> On Wed, 11 Jul 2007, Christoph Lameter wrote:
> > Of course you are the maintainer but you only authored a single patch
> > which was the original submission in all the time that SLOB was in the
> > tree. I keep having to clean up
Hi Christoph,
On Wed, 11 Jul 2007, Christoph Lameter wrote:
> Of course you are the maintainer but you only authored a single patch
> which was the original submission in all the time that SLOB was in the
> tree. I keep having to clean up the allocator that has--according to
> Pekka--more
On Tue, 10 Jul 2007, Matt Mackall wrote:
> > git log --pretty=short mm/slob.c
>
> A dozen trivial cleanups do not make you maintainer. Otherwise we'd
> all be sending our patches to Adrian rather than Linus.
Of course you are the maintainer but you only authored a single patch
which was the
On Tue, 10 Jul 2007, Matt Mackall wrote:
git log --pretty=short mm/slob.c
A dozen trivial cleanups do not make you maintainer. Otherwise we'd
all be sending our patches to Adrian rather than Linus.
Of course you are the maintainer but you only authored a single patch
which was the
Hi Christoph,
On Wed, 11 Jul 2007, Christoph Lameter wrote:
Of course you are the maintainer but you only authored a single patch
which was the original submission in all the time that SLOB was in the
tree. I keep having to clean up the allocator that has--according to
Pekka--more memory
On Wed, 11 Jul 2007, Pekka J Enberg wrote:
Hi Christoph,
On Wed, 11 Jul 2007, Christoph Lameter wrote:
Of course you are the maintainer but you only authored a single patch
which was the original submission in all the time that SLOB was in the
tree. I keep having to clean up the
On Wed, 11 Jul 2007, Christoph Lameter wrote:
But you did get 2.6.22 to compile it seems.
Here is the fix against 2.6.22-rc6-mm1 again.
I didn't get so far to compile with SLUB. There's some UML architecture
problem and SLOB missing __kmalloc which UML also needs.
Pekka J Enberg wrote:
Hi Christoph,
On Wed, 11 Jul 2007, Christoph Lameter wrote:
Of course you are the maintainer but you only authored a single patch
which was the original submission in all the time that SLOB was in the
tree. I keep having to clean up the allocator that has--according to
On Tue, Jul 10, 2007 at 06:37:42PM -0700, Christoph Lameter wrote:
> On Tue, 10 Jul 2007, Matt Mackall wrote:
>
> > You're delusional.
>
> Git log says otherwise:
>
> git log --pretty=short mm/slob.c
A dozen trivial cleanups do not make you maintainer. Otherwise we'd
all be sending our
On Tue, 10 Jul 2007, Matt Mackall wrote:
> You're delusional.
Git log says otherwise:
git log --pretty=short mm/slob.c
Author: Christoph Lameter <[EMAIL PROTECTED]>
Remove SLAB_CTOR_CONSTRUCTOR
Author: Christoph Lameter <[EMAIL PROTECTED]>
Slab allocators: Drop support for
On Tue, Jul 10, 2007 at 03:09:06PM -0700, Christoph Lameter wrote:
> On Tue, 10 Jul 2007, Nick Piggin wrote:
>
> > But last time this discussion came up, IIRC you ended up handwaving
> > about all the ways in which SLOB was broken but didn't actually come
> > up with any real problems. Matt
On Tue, 10 Jul 2007, Matt Mackall wrote:
> Without the parameter, as the other way doesn't compile in -mm1.
here is the patch that went into mm after mm1 was released.
---
mm/slub.c |4
1 file changed, 4 insertions(+)
Index: linux-2.6.22-rc6-mm1/mm/slub.c
On Tue, Jul 10, 2007 at 03:12:38PM -0700, Christoph Lameter wrote:
> On Tue, 10 Jul 2007, Matt Mackall wrote:
>
> > following as the best MemFree numbers after several boots each:
> >
> > SLAB: 54796
> > SLOB: 55044
> > SLUB: 53944
> > SLUB: 54788 (debug turned off)
>
> That was without
On Tue, 10 Jul 2007, Matt Mackall wrote:
> following as the best MemFree numbers after several boots each:
>
> SLAB: 54796
> SLOB: 55044
> SLUB: 53944
> SLUB: 54788 (debug turned off)
That was without "slub_debug" as a parameter or with !CONFIG_SLUB_DEBUG?
Data size and code size will decrease
On Tue, 10 Jul 2007, Nick Piggin wrote:
> But last time this discussion came up, IIRC you ended up handwaving
> about all the ways in which SLOB was broken but didn't actually come
> up with any real problems. Matt seemed willing to add those counters
> or whatever it was if/when doing so solved
Hi Matt,
On Tue, 10 Jul 2007, Matt Mackall wrote:
> Using 2.6.22-rc6-mm1 with a 64MB lguest and busybox, I'm seeing the
> following as the best MemFree numbers after several boots each:
>
> SLAB: 54796
> SLOB: 55044
> SLUB: 53944
> SLUB: 54788 (debug turned off)
>
> These numbers bounce around
On Tue, Jul 10, 2007 at 12:31:40PM +0300, Pekka Enberg wrote:
> Hi Nick,
>
> Pekka J Enberg wrote:
> >> That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
> >> debugging is disabled.
>
> On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> >Interesting. What kernel version
Pekka Enberg wrote:
Hi Nick,
Pekka J Enberg wrote:
> That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
> debugging is disabled.
On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Interesting. What kernel version are you using?
Linus' git head from yesterday so the
Hi Nick,
Pekka J Enberg wrote:
> That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
> debugging is disabled.
On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Interesting. What kernel version are you using?
Linus' git head from yesterday so the results are likely to be
On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Håvard Skinnemoen wrote:
> On 7/10/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
>
>> The only remaining known bug is arguably a problem in nommu that SLOB
>> shouldn't be papering over.
>
>
> I've got another one for you: SLOB ignores
Håvard Skinnemoen wrote:
On 7/10/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
The only remaining known bug is arguably a problem in nommu that SLOB
shouldn't be papering over.
I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so
using SLOB in combination with DMA and
On 7/10/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
The only remaining known bug is arguably a problem in nommu that SLOB
shouldn't be papering over.
I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so
using SLOB in combination with DMA and non-coherent architectures
causes
On Mon, Jul 09, 2007 at 07:11:03PM -0700, Christoph Lameter wrote:
> On Tue, 10 Jul 2007, Nick Piggin wrote:
>
> > It is reasonable to expect some help from maintainers, but I notice you
> > didn't even CC the SLOB maintainer in the patch to remove SLOB! So maybe
> > if you tried working a bit
Pekka J Enberg wrote:
Curious, /proc/meminfo immediately after boot shows:
SLUB (debugging enabled):
(none):~# cat /proc/meminfo
MemTotal:30260 kB
MemFree: 22096 kB
SLUB (debugging disabled):
(none):~# cat /proc/meminfo
MemTotal:30276 kB
MemFree: 22244 kB
Hi Christoph,
On Mon, 9 Jul 2007, Pekka Enberg wrote:
> > I assume with "slab external fragmentation" you mean allocating a
> > whole page for a slab when there are not enough objects to fill the
> > whole thing thus wasting memory? We could try to combat that by
> > packing multiple
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
It is reasonable to expect some help from maintainers, but I notice you
didn't even CC the SLOB maintainer in the patch to remove SLOB! So maybe
if you tried working a bit closer with him you could get better results?
The
Matt Mackall wrote:
On Tue, Jul 10, 2007 at 11:58:44AM +1000, Nick Piggin wrote:
Just a fancy way of saying roughly that memory waste will increase as
the size of the system increases. But that aspect of it I think is
not really a problem for non-tiny systems anyway because the waste
tends
On Tue, Jul 10, 2007 at 11:58:44AM +1000, Nick Piggin wrote:
> Christoph Lameter wrote:
> >On Tue, 10 Jul 2007, Nick Piggin wrote:
> >
> >
> >>>O(n) memory savings? What is that?
> >>
> >>Allocate n things and your memory waste is proportional to n (well that's
> >>O(n) waste, so I guess by
On Tue, Jul 10, 2007 at 11:58:44AM +1000, Nick Piggin wrote:
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
O(n) memory savings? What is that?
Allocate n things and your memory waste is proportional to n (well that's
O(n) waste, so I guess by savings I mean that SLOB's
Matt Mackall wrote:
On Tue, Jul 10, 2007 at 11:58:44AM +1000, Nick Piggin wrote:
Just a fancy way of saying roughly that memory waste will increase as
the size of the system increases. But that aspect of it I think is
not really a problem for non-tiny systems anyway because the waste
tends
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
It is reasonable to expect some help from maintainers, but I notice you
didn't even CC the SLOB maintainer in the patch to remove SLOB! So maybe
if you tried working a bit closer with him you could get better results?
The
Hi Christoph,
On Mon, 9 Jul 2007, Pekka Enberg wrote:
I assume with slab external fragmentation you mean allocating a
whole page for a slab when there are not enough objects to fill the
whole thing thus wasting memory? We could try to combat that by
packing multiple variable-sized slabs
Pekka J Enberg wrote:
Curious, /proc/meminfo immediately after boot shows:
SLUB (debugging enabled):
(none):~# cat /proc/meminfo
MemTotal:30260 kB
MemFree: 22096 kB
SLUB (debugging disabled):
(none):~# cat /proc/meminfo
MemTotal:30276 kB
MemFree: 22244 kB
On Mon, Jul 09, 2007 at 07:11:03PM -0700, Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
It is reasonable to expect some help from maintainers, but I notice you
didn't even CC the SLOB maintainer in the patch to remove SLOB! So maybe
if you tried working a bit closer
On 7/10/07, Matt Mackall [EMAIL PROTECTED] wrote:
The only remaining known bug is arguably a problem in nommu that SLOB
shouldn't be papering over.
I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so
using SLOB in combination with DMA and non-coherent architectures
causes data
Håvard Skinnemoen wrote:
On 7/10/07, Matt Mackall [EMAIL PROTECTED] wrote:
The only remaining known bug is arguably a problem in nommu that SLOB
shouldn't be papering over.
I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so
using SLOB in combination with DMA and
On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote:
Håvard Skinnemoen wrote:
On 7/10/07, Matt Mackall [EMAIL PROTECTED] wrote:
The only remaining known bug is arguably a problem in nommu that SLOB
shouldn't be papering over.
I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so
Hi Nick,
Pekka J Enberg wrote:
That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
debugging is disabled.
On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote:
Interesting. What kernel version are you using?
Linus' git head from yesterday so the results are likely to be
Pekka Enberg wrote:
Hi Nick,
Pekka J Enberg wrote:
That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
debugging is disabled.
On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote:
Interesting. What kernel version are you using?
Linus' git head from yesterday so the
On Tue, Jul 10, 2007 at 12:31:40PM +0300, Pekka Enberg wrote:
Hi Nick,
Pekka J Enberg wrote:
That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
debugging is disabled.
On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote:
Interesting. What kernel version are you using?
Hi Matt,
On Tue, 10 Jul 2007, Matt Mackall wrote:
Using 2.6.22-rc6-mm1 with a 64MB lguest and busybox, I'm seeing the
following as the best MemFree numbers after several boots each:
SLAB: 54796
SLOB: 55044
SLUB: 53944
SLUB: 54788 (debug turned off)
These numbers bounce around a lot
On Tue, 10 Jul 2007, Nick Piggin wrote:
But last time this discussion came up, IIRC you ended up handwaving
about all the ways in which SLOB was broken but didn't actually come
up with any real problems. Matt seemed willing to add those counters
or whatever it was if/when doing so solved a
On Tue, 10 Jul 2007, Matt Mackall wrote:
following as the best MemFree numbers after several boots each:
SLAB: 54796
SLOB: 55044
SLUB: 53944
SLUB: 54788 (debug turned off)
That was without slub_debug as a parameter or with !CONFIG_SLUB_DEBUG?
Data size and code size will decrease if you
On Tue, Jul 10, 2007 at 03:12:38PM -0700, Christoph Lameter wrote:
On Tue, 10 Jul 2007, Matt Mackall wrote:
following as the best MemFree numbers after several boots each:
SLAB: 54796
SLOB: 55044
SLUB: 53944
SLUB: 54788 (debug turned off)
That was without slub_debug as a
On Tue, 10 Jul 2007, Matt Mackall wrote:
Without the parameter, as the other way doesn't compile in -mm1.
here is the patch that went into mm after mm1 was released.
---
mm/slub.c |4
1 file changed, 4 insertions(+)
Index: linux-2.6.22-rc6-mm1/mm/slub.c
On Tue, Jul 10, 2007 at 03:09:06PM -0700, Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
But last time this discussion came up, IIRC you ended up handwaving
about all the ways in which SLOB was broken but didn't actually come
up with any real problems. Matt seemed
On Tue, 10 Jul 2007, Matt Mackall wrote:
You're delusional.
Git log says otherwise:
git log --pretty=short mm/slob.c
Author: Christoph Lameter [EMAIL PROTECTED]
Remove SLAB_CTOR_CONSTRUCTOR
Author: Christoph Lameter [EMAIL PROTECTED]
Slab allocators: Drop support for destructors
On Tue, Jul 10, 2007 at 06:37:42PM -0700, Christoph Lameter wrote:
On Tue, 10 Jul 2007, Matt Mackall wrote:
You're delusional.
Git log says otherwise:
git log --pretty=short mm/slob.c
A dozen trivial cleanups do not make you maintainer. Otherwise we'd
all be sending our patches to
On Mon, Jul 09, 2007 at 06:51:51PM -0700, Christoph Lameter wrote:
> On Tue, 10 Jul 2007, Nick Piggin wrote:
>
> > > O(n) memory savings? What is that?
> >
> > Allocate n things and your memory waste is proportional to n (well that's
> > O(n) waste, so I guess by savings I mean that SLOB's
On Tue, 10 Jul 2007, Nick Piggin wrote:
> It is reasonable to expect some help from maintainers, but I notice you
> didn't even CC the SLOB maintainer in the patch to remove SLOB! So maybe
> if you tried working a bit closer with him you could get better results?
The maintainers last patch to
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
I don't see any problems with maintaining SLOB. It is simple enough
that I was able to write a userspace test harness for it and hack
away at it after reading the code the first time for half an hour or
so. It is nothing even
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
O(n) memory savings? What is that?
Allocate n things and your memory waste is proportional to n (well that's
O(n) waste, so I guess by savings I mean that SLOB's memory saving compared
to SLUB are proportional to n).
n is
On Tue, 10 Jul 2007, Nick Piggin wrote:
> I don't see any problems with maintaining SLOB. It is simple enough
> that I was able to write a userspace test harness for it and hack
> away at it after reading the code the first time for half an hour or
> so. It is nothing even slightly comparable to
On Tue, 10 Jul 2007, Nick Piggin wrote:
> > O(n) memory savings? What is that?
>
> Allocate n things and your memory waste is proportional to n (well that's
> O(n) waste, so I guess by savings I mean that SLOB's memory saving compared
> to SLUB are proportional to n).
n is the size of the
Christoph Lameter wrote:
On Mon, 9 Jul 2007, Andrew Morton wrote:
I think the advantage that SLOB generates here is pretty minimal and is
easily offset by the problems of maintaining SLOB.
I don't get it. Have you got agreement from the small memory people
that the advantages of SLOB are
Christoph Lameter wrote:
On Mon, 9 Jul 2007, Nick Piggin wrote:
A reason for retaining slob would be that it has some O(n) memory saving
due to better packing, etc. Indeed that was the reason for merging it in
the first place. If slob no longer retains that advantage (wrt slub) then
we no
On Mon, Jul 09, 2007 at 09:51:16AM -0700, Andrew Morton wrote:
> On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
> wrote:
>
> > But yes the power of
> > two caches are a necessary design feature of SLAB/SLUB that allows O(1)
> > operations of kmalloc slabs which
On Sun, Jul 08, 2007 at 11:02:24AM -0700, Andrew Morton wrote:
> Guys, look at this the other way. Suppose we only had slub, and someone
> came along and said "here's a whole new allocator which saves 4.5k of
> text", would we merge it on that basis? Hell no, it's not worth it. What
> we might
First, WTF wasn't I cc:ed on this? Are you actually trying to me make
me fuming mad?
On Sat, Jul 07, 2007 at 08:50:01PM -0700, Christoph Lameter wrote:
> Maintenance of slab allocators becomes a problem as new features for
> allocators are developed. The SLOB allocator in particular has been
On Mon, 9 Jul 2007 10:26:08 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > I assume the tradeoff here is better packing versus having a ridiculous
> > number of caches. Is there any other cost?
> > Because even having 1024 caches wouldn't consume a terrible amount of
> > memory and
On Mon, 9 Jul 2007, Andrew Morton wrote:
> On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
> wrote:
>
> > But yes the power of
> > two caches are a necessary design feature of SLAB/SLUB that allows O(1)
> > operations of kmalloc slabs which in turns causes memory
On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> But yes the power of
> two caches are a necessary design feature of SLAB/SLUB that allows O(1)
> operations of kmalloc slabs which in turns causes memory wastage because
> of rounding of the alloc to the
On Mon, 9 Jul 2007, Pekka Enberg wrote:
> I assume with "slab external fragmentation" you mean allocating a
> whole page for a slab when there are not enough objects to fill the
> whole thing thus wasting memory? We could try to combat that by
> packing multiple variable-sized slabs within a
On Mon, 9 Jul 2007, Nick Piggin wrote:
> > A reason for retaining slob would be that it has some O(n) memory saving
> > due to better packing, etc. Indeed that was the reason for merging it in
> > the first place. If slob no longer retains that advantage (wrt slub) then
> > we no longer need
On Sun, 8 Jul 2007, Ingo Molnar wrote:
> actually, one real advantage of the SLOB is that it is a minimal, really
> simple allocator. Its text and data size is so small as well.
>
> here's the size comparison:
>
>textdata bss dec hex filename
> 10788 837 16
Hi Nick,
Pekka Enberg wrote:
> > adding some non-power-of-two kmalloc caches might help with internal
> > fragmentation.
On Mon, 9 Jul 2007, Nick Piggin wrote:
> That too, although of course it will work against the external
> fragmentation problem. This is more of an O(n) problem and may not
>
Hi Nick,
Pekka Enberg wrote:
> I assume with "slab external fragmentation" you mean allocating a
> whole page for a slab when there are not enough objects to fill the
> whole thing thus wasting memory?
On 7/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Yep. Without really analysing it, I
Ingo Molnar elte.hu> writes:
> A year ago the -rt kernel defaulted to the SLOB for a few releases, and
> barring some initial scalability issues (which were solved in -rt) it
> worked pretty well on generic PCs, so i dont buy the 'it doesnt work'
> argument either.
>
Last time I tried it, I
Pekka Enberg wrote:
Hi Nick,
On 7/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
SLOB contains several significant O(1) and also O(n) memory savings that
are so far impossible-by-design for SLUB. They are: slab external
fragmentation is significantly reduced; kmalloc internal fragmentation is
Hi Nick,
On 7/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
SLOB contains several significant O(1) and also O(n) memory savings that
are so far impossible-by-design for SLUB. They are: slab external
fragmentation is significantly reduced; kmalloc internal fragmentation is
significantly reduced;
Hi Nick,
On 7/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
SLOB contains several significant O(1) and also O(n) memory savings that
are so far impossible-by-design for SLUB. They are: slab external
fragmentation is significantly reduced; kmalloc internal fragmentation is
significantly reduced;
Pekka Enberg wrote:
Hi Nick,
On 7/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
SLOB contains several significant O(1) and also O(n) memory savings that
are so far impossible-by-design for SLUB. They are: slab external
fragmentation is significantly reduced; kmalloc internal fragmentation is
Ingo Molnar mingo at elte.hu writes:
A year ago the -rt kernel defaulted to the SLOB for a few releases, and
barring some initial scalability issues (which were solved in -rt) it
worked pretty well on generic PCs, so i dont buy the 'it doesnt work'
argument either.
Last time I tried it,
Hi Nick,
Pekka Enberg wrote:
I assume with slab external fragmentation you mean allocating a
whole page for a slab when there are not enough objects to fill the
whole thing thus wasting memory?
On 7/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
Yep. Without really analysing it, I guess
Hi Nick,
Pekka Enberg wrote:
adding some non-power-of-two kmalloc caches might help with internal
fragmentation.
On Mon, 9 Jul 2007, Nick Piggin wrote:
That too, although of course it will work against the external
fragmentation problem. This is more of an O(n) problem and may not
be
On Sun, 8 Jul 2007, Ingo Molnar wrote:
actually, one real advantage of the SLOB is that it is a minimal, really
simple allocator. Its text and data size is so small as well.
here's the size comparison:
textdata bss dec hex filename
10788 837 16 11641
On Mon, 9 Jul 2007, Nick Piggin wrote:
A reason for retaining slob would be that it has some O(n) memory saving
due to better packing, etc. Indeed that was the reason for merging it in
the first place. If slob no longer retains that advantage (wrt slub) then
we no longer need it.
On Mon, 9 Jul 2007, Pekka Enberg wrote:
I assume with slab external fragmentation you mean allocating a
whole page for a slab when there are not enough objects to fill the
whole thing thus wasting memory? We could try to combat that by
packing multiple variable-sized slabs within a single
On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
But yes the power of
two caches are a necessary design feature of SLAB/SLUB that allows O(1)
operations of kmalloc slabs which in turns causes memory wastage because
of rounding of the alloc to the next
On Mon, 9 Jul 2007, Andrew Morton wrote:
On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
But yes the power of
two caches are a necessary design feature of SLAB/SLUB that allows O(1)
operations of kmalloc slabs which in turns causes memory wastage
On Mon, 9 Jul 2007 10:26:08 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
I assume the tradeoff here is better packing versus having a ridiculous
number of caches. Is there any other cost?
Because even having 1024 caches wouldn't consume a terrible amount of
memory and I bet it
First, WTF wasn't I cc:ed on this? Are you actually trying to me make
me fuming mad?
On Sat, Jul 07, 2007 at 08:50:01PM -0700, Christoph Lameter wrote:
Maintenance of slab allocators becomes a problem as new features for
allocators are developed. The SLOB allocator in particular has been
On Sun, Jul 08, 2007 at 11:02:24AM -0700, Andrew Morton wrote:
Guys, look at this the other way. Suppose we only had slub, and someone
came along and said here's a whole new allocator which saves 4.5k of
text, would we merge it on that basis? Hell no, it's not worth it. What
we might do is
On Mon, Jul 09, 2007 at 09:51:16AM -0700, Andrew Morton wrote:
On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
But yes the power of
two caches are a necessary design feature of SLAB/SLUB that allows O(1)
operations of kmalloc slabs which in turns
Christoph Lameter wrote:
On Mon, 9 Jul 2007, Nick Piggin wrote:
A reason for retaining slob would be that it has some O(n) memory saving
due to better packing, etc. Indeed that was the reason for merging it in
the first place. If slob no longer retains that advantage (wrt slub) then
we no
Christoph Lameter wrote:
On Mon, 9 Jul 2007, Andrew Morton wrote:
I think the advantage that SLOB generates here is pretty minimal and is
easily offset by the problems of maintaining SLOB.
I don't get it. Have you got agreement from the small memory people
that the advantages of SLOB are
On Tue, 10 Jul 2007, Nick Piggin wrote:
O(n) memory savings? What is that?
Allocate n things and your memory waste is proportional to n (well that's
O(n) waste, so I guess by savings I mean that SLOB's memory saving compared
to SLUB are proportional to n).
n is the size of the object?
On Tue, 10 Jul 2007, Nick Piggin wrote:
I don't see any problems with maintaining SLOB. It is simple enough
that I was able to write a userspace test harness for it and hack
away at it after reading the code the first time for half an hour or
so. It is nothing even slightly comparable to the
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
O(n) memory savings? What is that?
Allocate n things and your memory waste is proportional to n (well that's
O(n) waste, so I guess by savings I mean that SLOB's memory saving compared
to SLUB are proportional to n).
n is
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
I don't see any problems with maintaining SLOB. It is simple enough
that I was able to write a userspace test harness for it and hack
away at it after reading the code the first time for half an hour or
so. It is nothing even
On Tue, 10 Jul 2007, Nick Piggin wrote:
It is reasonable to expect some help from maintainers, but I notice you
didn't even CC the SLOB maintainer in the patch to remove SLOB! So maybe
if you tried working a bit closer with him you could get better results?
The maintainers last patch to SLOB
On Mon, Jul 09, 2007 at 06:51:51PM -0700, Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
O(n) memory savings? What is that?
Allocate n things and your memory waste is proportional to n (well that's
O(n) waste, so I guess by savings I mean that SLOB's memory saving
Andrew Morton wrote:
On Sun, 8 Jul 2007 09:51:19 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
A year ago the -rt kernel defaulted to the SLOB for a few releases, and
barring some initial scalability issues (which were solved in -rt) it
worked pretty well on generic PCs, so i dont buy the 'it
On Sun, 8 Jul 2007 09:51:19 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> (added Matt to the Cc: list)
>
> * Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > Maintenance of slab allocators becomes a problem as new features for
> > allocators are developed. The SLOB allocator in
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >cool. I was referring to something else: people were running -rt on
> >their beefy desktop boxes with several gigs of RAM they complained
> >about the slowdown that is caused by SLOB's linear list walking.
>
> That is what I meant by scalable to
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
I said exactly the same thing last time this came up. I would love to
remove code if its functionality can be adequately replaced by
existing code, but I think your reasons for removing SLOB aren't that
good, and just handwaving
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> I said exactly the same thing last time this came up. I would love to
> remove code if its functionality can be adequately replaced by
> existing code, but I think your reasons for removing SLOB aren't that
> good, and just handwaving away the
Ingo Molnar wrote:
(added Matt to the Cc: list)
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
Maintenance of slab allocators becomes a problem as new features for
allocators are developed. The SLOB allocator in particular has been
lagging behind in many ways in the past:
- Had no support
1 - 100 of 110 matches
Mail list logo
