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 t
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 memor
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 or
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
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 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:
> 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 "slub_de
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 a
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
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
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 ARCH_KMALLOC
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 non-cohere
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
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 clo
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 variable-size
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 main
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 not
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
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
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 SLO
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 sli
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 th
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 t
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
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 pre
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 lo
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
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 d
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 laggi
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 nex
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 singl
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 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 1164
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
> b
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
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
si
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; o
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 particular
* 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 larg
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 awa
* 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 signifi
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
(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 for SLAB_DES
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 for SLAB_DESTROY_BY_RCU for years (but no one noticed)
- Still has no support for slab reclaim counter
55 matches
Mail list logo
