* [patch 1/3] slob: rework freelist handling
@ 2007-05-22 7:39 Nick Piggin
2007-05-22 7:39 ` [patch 2/3] slob: remove bigblock tracking Nick Piggin
2007-05-22 14:53 ` [patch 1/3] slob: rework freelist handling Matt Mackall
0 siblings, 2 replies; 66+ messages in thread
From: Nick Piggin @ 2007-05-22 7:39 UTC (permalink / raw)
To: Andrew Morton, Matt Mackall, Linux Memory Management List
Here are some patches I have been working on for SLOB, which makes
it significantly faster, and also using less dynamic memory... at
the cost of being slightly larger static footprint and more complex
code.
Matt was happy for the first 2 to go into -mm (and hasn't seen patch 3 yet).
--
Improve slob by turning the freelist into a list of pages using struct page
fields, then each page has a singly linked freelist of slob blocks via a
pointer in the struct page.
- The first benefit is that the slob freelists can be indexed by a smaller
type (2 bytes, if the PAGE_SIZE is reasonable).
- Next is that freeing is much quicker because it does not have to traverse
the entire freelist. Allocation can be slightly faster too, because we can
skip almost-full freelist pages completely.
- Slob pages are then freed immediately when they become empty, rather than
having a periodic timer try to free them. This gives efficiency and memory
consumption improvement.
Then, we don't encode seperate size and next fields into each slob block,
rather we use the sign bit to distinguish between "size" or "next". Then
size 1 blocks contain a "next" offset, and others contain the "size" in
the first unit and "next" in the second unit.
- This allows minimum slob allocation alignment to go from 8 bytes to 2
bytes on 32-bit and 12 bytes to 2 bytes on 64-bit. In practice, it is
best to align them to word size, however some architectures (eg. cris)
could gain space savings from turning off this extra alignment.
Then, make kmalloc use its own slob_block at the front of the allocation
in order to encode allocation size, rather than rely on not overwriting
slob's existing header block.
- This reduces kmalloc allocation overhead similarly to alignment reductions.
- Decouples kmalloc layer from the slob allocator.
Then, add a page flag specific to slob pages.
- This means kfree of a page aligned slob block doesn't have to traverse
the bigblock list.
I would get benchmarks, but my test box's network doesn't come up with
slob before this patch. I think something is timing out. Anyway, things
are faster after the patch.
Code size goes up about 1K, however dynamic memory usage _should_ be
lower even on relatively small memory systems.
Future todo item is to restore the cyclic free list search, rather than
to always begin at the start.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
mm/slob.c | 271 +++++++++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 200 insertions(+), 71 deletions(-)
Index: linux-2.6/mm/slob.c
===================================================================
--- linux-2.6.orig/mm/slob.c
+++ linux-2.6/mm/slob.c
@@ -7,53 +7,148 @@
*
* The core of SLOB is a traditional K&R style heap allocator, with
* support for returning aligned objects. The granularity of this
- * allocator is 8 bytes on x86, though it's perhaps possible to reduce
- * this to 4 if it's deemed worth the effort. The slob heap is a
- * singly-linked list of pages from __get_free_page, grown on demand
- * and allocation from the heap is currently first-fit.
+ * allocator is 4 bytes on 32-bit and 8 bytes on 64-bit, though it
+ * could be as low as 2 if the compiler alignment requirements allow.
+ *
+ * The slob heap is a linked list of pages from __get_free_page, and
+ * within each page, there is a singly-linked list of free blocks (slob_t).
+ * The heap is grown on demand and allocation from the heap is currently
+ * first-fit.
*
* Above this is an implementation of kmalloc/kfree. Blocks returned
- * from kmalloc are 8-byte aligned and prepended with a 8-byte header.
+ * from kmalloc are 4-byte aligned and prepended with a 4-byte header.
* If kmalloc is asked for objects of PAGE_SIZE or larger, it calls
* __get_free_pages directly so that it can return page-aligned blocks
* and keeps a linked list of such pages and their orders. These
* objects are detected in kfree() by their page alignment.
*
* SLAB is emulated on top of SLOB by simply calling constructors and
- * destructors for every SLAB allocation. Objects are returned with
- * the 8-byte alignment unless the SLAB_HWCACHE_ALIGN flag is
- * set, in which case the low-level allocator will fragment blocks to
- * create the proper alignment. Again, objects of page-size or greater
- * are allocated by calling __get_free_pages. As SLAB objects know
- * their size, no separate size bookkeeping is necessary and there is
- * essentially no allocation space overhead.
+ * destructors for every SLAB allocation. Objects are returned with the
+ * 4-byte alignment unless the SLAB_HWCACHE_ALIGN flag is set, in which
+ * case the low-level allocator will fragment blocks to create the proper
+ * alignment. Again, objects of page-size or greater are allocated by
+ * calling __get_free_pages. As SLAB objects know their size, no separate
+ * size bookkeeping is necessary and there is essentially no allocation
+ * space overhead.
*/
+#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/mm.h>
#include <linux/cache.h>
#include <linux/init.h>
#include <linux/module.h>
-#include <linux/timer.h>
#include <linux/rcupdate.h>
+#include <linux/list.h>
+#include <asm/atomic.h>
+
+/* SLOB_MIN_ALIGN == sizeof(long) */
+#if BITS_PER_BYTE == 32
+#define SLOB_MIN_ALIGN 4
+#else
+#define SLOB_MIN_ALIGN 8
+#endif
+
+/*
+ * slob_block has a field 'units', which indicates size of block if +ve,
+ * or offset of next block if -ve (in SLOB_UNITs).
+ *
+ * Free blocks of size 1 unit simply contain the offset of the next block.
+ * Those with larger size contain their size in the first SLOB_UNIT of
+ * memory, and the offset of the next free block in the second SLOB_UNIT.
+ */
+#if PAGE_SIZE <= (32767 * SLOB_MIN_ALIGN)
+typedef s16 slobidx_t;
+#else
+typedef s32 slobidx_t;
+#endif
+/*
+ * Align struct slob_block to long for now, but can some embedded
+ * architectures get away with less?
+ */
struct slob_block {
- int units;
- struct slob_block *next;
-};
+ slobidx_t units;
+} __attribute__((aligned(SLOB_MIN_ALIGN)));
typedef struct slob_block slob_t;
+/*
+ * We use struct page fields to manage some slob allocation aspects,
+ * however to avoid the horrible mess in include/linux/mm_types.h, we'll
+ * just define our own struct page type variant here.
+ */
+struct slob_page {
+ union {
+ struct {
+ unsigned long flags; /* mandatory */
+ atomic_t _count; /* mandatory */
+ slobidx_t units; /* free units left in page */
+ unsigned long pad[2];
+ slob_t *free; /* first free slob_t in page */
+ struct list_head list; /* linked list of free pages */
+ };
+ struct page page;
+ };
+};
+static inline void struct_slob_page_wrong_size(void)
+{ BUILD_BUG_ON(sizeof(struct slob_page) != sizeof(struct page)); }
+
+/*
+ * free_slob_page: call before a slob_page is returned to the page allocator.
+ */
+static inline void free_slob_page(struct slob_page *sp)
+{
+ reset_page_mapcount(&sp->page);
+ sp->page.mapping = NULL;
+}
+
+/*
+ * All (partially) free slob pages go on this list.
+ */
+static LIST_HEAD(free_slob_pages);
+
+/*
+ * slob_page: True for all slob pages (false for bigblock pages)
+ */
+static inline int slob_page(struct slob_page *sp)
+{
+ return test_bit(PG_active, &sp->flags);
+}
+
+static inline void set_slob_page(struct slob_page *sp)
+{
+ __set_bit(PG_active, &sp->flags);
+}
+
+static inline void clear_slob_page(struct slob_page *sp)
+{
+ __clear_bit(PG_active, &sp->flags);
+}
+
+/*
+ * slob_page_free: true for pages on free_slob_pages list.
+ */
+static inline int slob_page_free(struct slob_page *sp)
+{
+ return test_bit(PG_private, &sp->flags);
+}
+
+static inline void set_slob_page_free(struct slob_page *sp)
+{
+ list_add(&sp->list, &free_slob_pages);
+ __set_bit(PG_private, &sp->flags);
+}
+
+static inline void clear_slob_page_free(struct slob_page *sp)
+{
+ list_del(&sp->list);
+ __clear_bit(PG_private, &sp->flags);
+}
+
#define SLOB_UNIT sizeof(slob_t)
#define SLOB_UNITS(size) (((size) + SLOB_UNIT - 1)/SLOB_UNIT)
#define SLOB_ALIGN L1_CACHE_BYTES
-struct bigblock {
- int order;
- void *pages;
- struct bigblock *next;
-};
-typedef struct bigblock bigblock_t;
-
/*
* struct slob_rcu is inserted at the tail of allocated slob blocks, which
* were created with a SLAB_DESTROY_BY_RCU slab. slob_rcu is used to free
@@ -64,103 +159,240 @@ struct slob_rcu {
int size;
};
-static slob_t arena = { .next = &arena, .units = 1 };
-static slob_t *slobfree = &arena;
-static bigblock_t *bigblocks;
+/*
+ * slob_lock protects all slob allocator structures.
+ */
static DEFINE_SPINLOCK(slob_lock);
-static DEFINE_SPINLOCK(block_lock);
-static void slob_free(void *b, int size);
-static void slob_timer_cbk(void);
+/*
+ * Encode the given size and next info into a free slob block s.
+ */
+static void set_slob(slob_t *s, slobidx_t size, slob_t *next)
+{
+ slob_t *base = (slob_t *)((unsigned long)s & PAGE_MASK);
+ slobidx_t offset = next - base;
+ if (size > 1) {
+ s[0].units = size;
+ s[1].units = offset;
+ } else
+ s[0].units = -offset;
+}
-static void *slob_alloc(size_t size, gfp_t gfp, int align)
+/*
+ * Return the size of a slob block.
+ */
+static slobidx_t slob_units(slob_t *s)
+{
+ if (s->units > 0)
+ return s->units;
+ return 1;
+}
+
+/*
+ * Return the next free slob block pointer after this one.
+ */
+static slob_t *slob_next(slob_t *s)
+{
+ slob_t *base = (slob_t *)((unsigned long)s & PAGE_MASK);
+ slobidx_t next;
+
+ if (s[0].units < 0)
+ next = -s[0].units;
+ else
+ next = s[1].units;
+ return base+next;
+}
+
+/*
+ * Returns true if s is the last free block in its page.
+ */
+static int slob_last(slob_t *s)
+{
+ return !((unsigned long)slob_next(s) & ~PAGE_MASK);
+}
+
+/*
+ * Allocate a slob block within a given slob_page sp.
+ */
+static void *slob_page_alloc(struct slob_page *sp, size_t size, int align)
{
slob_t *prev, *cur, *aligned = 0;
int delta = 0, units = SLOB_UNITS(size);
- unsigned long flags;
- spin_lock_irqsave(&slob_lock, flags);
- prev = slobfree;
- for (cur = prev->next; ; prev = cur, cur = cur->next) {
+ for (prev = NULL, cur = sp->free; ; prev = cur, cur = slob_next(cur)) {
+ slobidx_t avail = slob_units(cur);
+
if (align) {
aligned = (slob_t *)ALIGN((unsigned long)cur, align);
delta = aligned - cur;
}
- if (cur->units >= units + delta) { /* room enough? */
+ if (avail >= units + delta) { /* room enough? */
+ slob_t *next;
+
if (delta) { /* need to fragment head to align? */
- aligned->units = cur->units - delta;
- aligned->next = cur->next;
- cur->next = aligned;
- cur->units = delta;
+ next = slob_next(cur);
+ set_slob(aligned, avail - delta, next);
+ set_slob(cur, delta, aligned);
prev = cur;
cur = aligned;
+ avail = slob_units(cur);
}
- if (cur->units == units) /* exact fit? */
- prev->next = cur->next; /* unlink */
- else { /* fragment */
- prev->next = cur + units;
- prev->next->units = cur->units - units;
- prev->next->next = cur->next;
- cur->units = units;
+ next = slob_next(cur);
+ if (avail == units) { /* exact fit? unlink. */
+ if (prev)
+ set_slob(prev, slob_units(prev), next);
+ else
+ sp->free = next;
+ } else { /* fragment */
+ if (prev)
+ set_slob(prev, slob_units(prev), cur + units);
+ else
+ sp->free = cur + units;
+ set_slob(cur + units, avail - units, next);
}
- slobfree = prev;
- spin_unlock_irqrestore(&slob_lock, flags);
+ sp->units -= units;
+ if (!sp->units)
+ clear_slob_page_free(sp);
return cur;
}
- if (cur == slobfree) {
- spin_unlock_irqrestore(&slob_lock, flags);
+ if (slob_last(cur))
+ return NULL;
+ }
+}
- if (size == PAGE_SIZE) /* trying to shrink arena? */
- return 0;
+/*
+ * slob_alloc: entry point into the slob allocator.
+ */
+static void *slob_alloc(size_t size, gfp_t gfp, int align)
+{
+ struct slob_page *sp;
+ slob_t *b = NULL;
+ unsigned long flags;
- cur = (slob_t *)__get_free_page(gfp);
- if (!cur)
- return 0;
-
- slob_free(cur, PAGE_SIZE);
- spin_lock_irqsave(&slob_lock, flags);
- cur = slobfree;
+ spin_lock_irqsave(&slob_lock, flags);
+ /* Iterate through each partially free page, try to find room */
+ list_for_each_entry(sp, &free_slob_pages, list) {
+ if (sp->units >= SLOB_UNITS(size)) {
+ b = slob_page_alloc(sp, size, align);
+ if (b)
+ break;
}
}
+ spin_unlock_irqrestore(&slob_lock, flags);
+
+ /* Not enough space: must allocate a new page */
+ if (!b) {
+ b = (slob_t *)__get_free_page(gfp);
+ if (!b)
+ return 0;
+ sp = (struct slob_page *)virt_to_page(b);
+ set_slob_page(sp);
+
+ spin_lock_irqsave(&slob_lock, flags);
+ sp->units = SLOB_UNITS(PAGE_SIZE);
+ sp->free = b;
+ INIT_LIST_HEAD(&sp->list);
+ set_slob(b, SLOB_UNITS(PAGE_SIZE), b + SLOB_UNITS(PAGE_SIZE));
+ set_slob_page_free(sp);
+ b = slob_page_alloc(sp, size, align);
+ BUG_ON(!b);
+ spin_unlock_irqrestore(&slob_lock, flags);
+ }
+ return b;
}
+/*
+ * slob_free: entry point into the slob allocator.
+ */
static void slob_free(void *block, int size)
{
- slob_t *cur, *b = (slob_t *)block;
+ struct slob_page *sp;
+ slob_t *prev, *next, *b = (slob_t *)block;
+ slobidx_t units;
unsigned long flags;
if (!block)
return;
+ BUG_ON(!size);
- if (size)
- b->units = SLOB_UNITS(size);
+ sp = (struct slob_page *)virt_to_page(block);
+ units = SLOB_UNITS(size);
- /* Find reinsertion point */
spin_lock_irqsave(&slob_lock, flags);
- for (cur = slobfree; !(b > cur && b < cur->next); cur = cur->next)
- if (cur >= cur->next && (b > cur || b < cur->next))
- break;
-
- if (b + b->units == cur->next) {
- b->units += cur->next->units;
- b->next = cur->next->next;
- } else
- b->next = cur->next;
- if (cur + cur->units == b) {
- cur->units += b->units;
- cur->next = b->next;
- } else
- cur->next = b;
+ if (sp->units + units == SLOB_UNITS(PAGE_SIZE)) {
+ /* Go directly to page allocator. Do not pass slob allocator */
+ if (slob_page_free(sp))
+ clear_slob_page_free(sp);
+ clear_slob_page(sp);
+ free_slob_page(sp);
+ free_page((unsigned long)b);
+ goto out;
+ }
- slobfree = cur;
+ if (!slob_page_free(sp)) {
+ /* This slob page is about to become partially free. Easy! */
+ sp->units = units;
+ sp->free = b;
+ set_slob(b, units,
+ (void *)((unsigned long)(b +
+ SLOB_UNITS(PAGE_SIZE)) & PAGE_MASK));
+ set_slob_page_free(sp);
+ goto out;
+ }
+
+ /*
+ * Otherwise the page is already partially free, so find reinsertion
+ * point.
+ */
+ sp->units += units;
+
+ if (b < sp->free) {
+ set_slob(b, units, sp->free);
+ sp->free = b;
+ } else {
+ prev = sp->free;
+ next = slob_next(prev);
+ while (b > next) {
+ prev = next;
+ next = slob_next(prev);
+ }
+ if (!slob_last(prev) && b + units == next) {
+ units += slob_units(next);
+ set_slob(b, units, slob_next(next));
+ } else
+ set_slob(b, units, next);
+
+ if (prev + slob_units(prev) == b) {
+ units = slob_units(b) + slob_units(prev);
+ set_slob(prev, units, slob_next(b));
+ } else
+ set_slob(prev, slob_units(prev), b);
+ }
+out:
spin_unlock_irqrestore(&slob_lock, flags);
}
+/*
+ * End of slob allocator proper. Begin kmem_cache_alloc and kmalloc frontend.
+ */
+
+struct bigblock {
+ int order;
+ void *pages;
+ struct bigblock *next;
+};
+typedef struct bigblock bigblock_t;
+
+static bigblock_t *bigblocks;
+
+static DEFINE_SPINLOCK(block_lock);
+
+
void *__kmalloc(size_t size, gfp_t gfp)
{
slob_t *m;
@@ -169,7 +401,9 @@ void *__kmalloc(size_t size, gfp_t gfp)
if (size < PAGE_SIZE - SLOB_UNIT) {
m = slob_alloc(size + SLOB_UNIT, gfp, 0);
- return m ? (void *)(m + 1) : 0;
+ if (m)
+ m->units = size;
+ return m+1;
}
bb = slob_alloc(sizeof(bigblock_t), gfp, 0);
@@ -227,14 +461,17 @@ EXPORT_SYMBOL(krealloc);
void kfree(const void *block)
{
+ struct slob_page *sp;
+ slob_t *m;
bigblock_t *bb, **last = &bigblocks;
unsigned long flags;
if (!block)
return;
- if (!((unsigned long)block & (PAGE_SIZE-1))) {
- /* might be on the big block list */
+ sp = (struct slob_page *)virt_to_page(block);
+ if (!slob_page(sp)) {
+ /* on the big block list */
spin_lock_irqsave(&block_lock, flags);
for (bb = bigblocks; bb; last = &bb->next, bb = bb->next) {
if (bb->pages == block) {
@@ -246,9 +483,12 @@ void kfree(const void *block)
}
}
spin_unlock_irqrestore(&block_lock, flags);
+ WARN_ON(1);
+ return;
}
- slob_free((slob_t *)block - 1, 0);
+ m = (slob_t *)block - 1;
+ slob_free(m, m->units + SLOB_UNIT);
return;
}
@@ -256,13 +496,15 @@ EXPORT_SYMBOL(kfree);
size_t ksize(const void *block)
{
+ struct slob_page *sp;
bigblock_t *bb;
unsigned long flags;
if (!block)
return 0;
- if (!((unsigned long)block & (PAGE_SIZE-1))) {
+ sp = (struct slob_page *)virt_to_page(block);
+ if (!slob_page(sp)) {
spin_lock_irqsave(&block_lock, flags);
for (bb = bigblocks; bb; bb = bb->next)
if (bb->pages == block) {
@@ -272,7 +514,7 @@ size_t ksize(const void *block)
spin_unlock_irqrestore(&block_lock, flags);
}
- return ((slob_t *)block - 1)->units * SLOB_UNIT;
+ return ((slob_t *)block - 1)->units + SLOB_UNIT;
}
struct kmem_cache {
@@ -385,9 +627,6 @@ const char *kmem_cache_name(struct kmem_
}
EXPORT_SYMBOL(kmem_cache_name);
-static struct timer_list slob_timer = TIMER_INITIALIZER(
- (void (*)(unsigned long))slob_timer_cbk, 0, 0);
-
int kmem_cache_shrink(struct kmem_cache *d)
{
return 0;
@@ -401,15 +640,4 @@ int kmem_ptr_validate(struct kmem_cache
void __init kmem_cache_init(void)
{
- slob_timer_cbk();
-}
-
-static void slob_timer_cbk(void)
-{
- void *p = slob_alloc(PAGE_SIZE, 0, PAGE_SIZE-1);
-
- if (p)
- free_page((unsigned long)p);
-
- mod_timer(&slob_timer, jiffies + HZ);
}
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* [patch 2/3] slob: remove bigblock tracking
2007-05-22 7:39 [patch 1/3] slob: rework freelist handling Nick Piggin
@ 2007-05-22 7:39 ` Nick Piggin
2007-05-22 7:41 ` [patch 3/3] slob: improved alignment handling Nick Piggin
2007-05-22 14:53 ` [patch 1/3] slob: rework freelist handling Matt Mackall
1 sibling, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-22 7:39 UTC (permalink / raw)
To: Andrew Morton, Matt Mackall, Linux Memory Management List
Remove the bigblock lists in favour of using compound pages and going
directly to the page allocator. Allocation size is stored in page->private,
which also makes ksize more accurate than it previously was.
Saves ~.5K of code, and 12-24 bytes overhead per >= PAGE_SIZE allocation.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/slob.c
===================================================================
--- linux-2.6.orig/mm/slob.c
+++ linux-2.6/mm/slob.c
@@ -18,9 +18,11 @@
* Above this is an implementation of kmalloc/kfree. Blocks returned
* from kmalloc are 4-byte aligned and prepended with a 4-byte header.
* If kmalloc is asked for objects of PAGE_SIZE or larger, it calls
- * __get_free_pages directly so that it can return page-aligned blocks
- * and keeps a linked list of such pages and their orders. These
- * objects are detected in kfree() by their page alignment.
+ * __get_free_pages directly, allocating compound pages so the page order
+ * does not have to be separately tracked, and also stores the exact
+ * allocation size in page->private so that it can be used to accurately
+ * provide ksize(). These objects are detected in kfree() because slob_page()
+ * is false for them.
*
* SLAB is emulated on top of SLOB by simply calling constructors and
* destructors for every SLAB allocation. Objects are returned with the
@@ -29,7 +31,8 @@
* alignment. Again, objects of page-size or greater are allocated by
* calling __get_free_pages. As SLAB objects know their size, no separate
* size bookkeeping is necessary and there is essentially no allocation
- * space overhead.
+ * space overhead, and compound pages aren't needed for multi-page
+ * allocations.
*/
#include <linux/kernel.h>
@@ -381,48 +384,26 @@ out:
* End of slob allocator proper. Begin kmem_cache_alloc and kmalloc frontend.
*/
-struct bigblock {
- int order;
- void *pages;
- struct bigblock *next;
-};
-typedef struct bigblock bigblock_t;
-
-static bigblock_t *bigblocks;
-
-static DEFINE_SPINLOCK(block_lock);
-
-
void *__kmalloc(size_t size, gfp_t gfp)
{
- slob_t *m;
- bigblock_t *bb;
- unsigned long flags;
-
if (size < PAGE_SIZE - SLOB_UNIT) {
+ slob_t *m;
m = slob_alloc(size + SLOB_UNIT, gfp, 0);
if (m)
m->units = size;
return m+1;
- }
-
- bb = slob_alloc(sizeof(bigblock_t), gfp, 0);
- if (!bb)
- return 0;
-
- bb->order = get_order(size);
- bb->pages = (void *)__get_free_pages(gfp, bb->order);
+ } else {
+ void *ret;
- if (bb->pages) {
- spin_lock_irqsave(&block_lock, flags);
- bb->next = bigblocks;
- bigblocks = bb;
- spin_unlock_irqrestore(&block_lock, flags);
- return bb->pages;
+ ret = (void *) __get_free_pages(gfp | __GFP_COMP,
+ get_order(size));
+ if (ret) {
+ struct page *page;
+ page = virt_to_page(ret);
+ page->private = size;
+ }
+ return ret;
}
-
- slob_free(bb, sizeof(bigblock_t));
- return 0;
}
EXPORT_SYMBOL(__kmalloc);
@@ -462,59 +443,33 @@ EXPORT_SYMBOL(krealloc);
void kfree(const void *block)
{
struct slob_page *sp;
- slob_t *m;
- bigblock_t *bb, **last = &bigblocks;
- unsigned long flags;
if (!block)
return;
sp = (struct slob_page *)virt_to_page(block);
- if (!slob_page(sp)) {
- /* on the big block list */
- spin_lock_irqsave(&block_lock, flags);
- for (bb = bigblocks; bb; last = &bb->next, bb = bb->next) {
- if (bb->pages == block) {
- *last = bb->next;
- spin_unlock_irqrestore(&block_lock, flags);
- free_pages((unsigned long)block, bb->order);
- slob_free(bb, sizeof(bigblock_t));
- return;
- }
- }
- spin_unlock_irqrestore(&block_lock, flags);
- WARN_ON(1);
- return;
- }
-
- m = (slob_t *)block - 1;
- slob_free(m, m->units + SLOB_UNIT);
- return;
+ if (slob_page(sp)) {
+ slob_t *m = (slob_t *)block - 1;
+ slob_free(m, m->units + SLOB_UNIT);
+ } else
+ put_page(&sp->page);
}
EXPORT_SYMBOL(kfree);
+/* can't use ksize for kmem_cache_alloc memory, only kmalloc */
size_t ksize(const void *block)
{
struct slob_page *sp;
- bigblock_t *bb;
- unsigned long flags;
if (!block)
return 0;
sp = (struct slob_page *)virt_to_page(block);
- if (!slob_page(sp)) {
- spin_lock_irqsave(&block_lock, flags);
- for (bb = bigblocks; bb; bb = bb->next)
- if (bb->pages == block) {
- spin_unlock_irqrestore(&slob_lock, flags);
- return PAGE_SIZE << bb->order;
- }
- spin_unlock_irqrestore(&block_lock, flags);
- }
-
- return ((slob_t *)block - 1)->units + SLOB_UNIT;
+ if (slob_page(sp))
+ return ((slob_t *)block - 1)->units + SLOB_UNIT;
+ else
+ return sp->page.private;
}
struct kmem_cache {
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* [patch 3/3] slob: improved alignment handling
2007-05-22 7:39 ` [patch 2/3] slob: remove bigblock tracking Nick Piggin
@ 2007-05-22 7:41 ` Nick Piggin
0 siblings, 0 replies; 66+ messages in thread
From: Nick Piggin @ 2007-05-22 7:41 UTC (permalink / raw)
To: Andrew Morton, Matt Mackall, Linux Memory Management List
Remove the core slob allocator's minimum alignment restrictions, and
instead introduce the alignment restrictions at the slab API layer.
This lets us heed the ARCH_KMALLOC/SLAB_MINALIGN directives, and also
use __alignof__ (unsigned long) for the default alignment (which should
allow relaxed alignment architectures to take better advantage of SLOB's
small minimum alignment).
Signed-off-by: Nick Piggin <npiggin@suse.de>
Index: linux-2.6/mm/slob.c
===================================================================
--- linux-2.6.orig/mm/slob.c
+++ linux-2.6/mm/slob.c
@@ -7,8 +7,8 @@
*
* The core of SLOB is a traditional K&R style heap allocator, with
* support for returning aligned objects. The granularity of this
- * allocator is 4 bytes on 32-bit and 8 bytes on 64-bit, though it
- * could be as low as 2 if the compiler alignment requirements allow.
+ * allocator is as little as 2 bytes, however typically most architectures
+ * will require 4 bytes on 32-bit and 8 bytes on 64-bit.
*
* The slob heap is a linked list of pages from __get_free_page, and
* within each page, there is a singly-linked list of free blocks (slob_t).
@@ -16,7 +16,7 @@
* first-fit.
*
* Above this is an implementation of kmalloc/kfree. Blocks returned
- * from kmalloc are 4-byte aligned and prepended with a 4-byte header.
+ * from kmalloc are prepended with a 4-byte header with the kmalloc size.
* If kmalloc is asked for objects of PAGE_SIZE or larger, it calls
* __get_free_pages directly, allocating compound pages so the page order
* does not have to be separately tracked, and also stores the exact
@@ -45,13 +45,6 @@
#include <linux/list.h>
#include <asm/atomic.h>
-/* SLOB_MIN_ALIGN == sizeof(long) */
-#if BITS_PER_BYTE == 32
-#define SLOB_MIN_ALIGN 4
-#else
-#define SLOB_MIN_ALIGN 8
-#endif
-
/*
* slob_block has a field 'units', which indicates size of block if +ve,
* or offset of next block if -ve (in SLOB_UNITs).
@@ -60,19 +53,15 @@
* Those with larger size contain their size in the first SLOB_UNIT of
* memory, and the offset of the next free block in the second SLOB_UNIT.
*/
-#if PAGE_SIZE <= (32767 * SLOB_MIN_ALIGN)
+#if PAGE_SIZE <= (32767 * 2)
typedef s16 slobidx_t;
#else
typedef s32 slobidx_t;
#endif
-/*
- * Align struct slob_block to long for now, but can some embedded
- * architectures get away with less?
- */
struct slob_block {
slobidx_t units;
-} __attribute__((aligned(SLOB_MIN_ALIGN)));
+};
typedef struct slob_block slob_t;
/*
@@ -384,14 +373,25 @@ out:
* End of slob allocator proper. Begin kmem_cache_alloc and kmalloc frontend.
*/
+#ifndef ARCH_KMALLOC_MINALIGN
+#define ARCH_KMALLOC_MINALIGN __alignof__(unsigned long)
+#endif
+
+#ifndef ARCH_SLAB_MINALIGN
+#define ARCH_SLAB_MINALIGN __alignof__(unsigned long)
+#endif
+
+
void *__kmalloc(size_t size, gfp_t gfp)
{
- if (size < PAGE_SIZE - SLOB_UNIT) {
- slob_t *m;
- m = slob_alloc(size + SLOB_UNIT, gfp, 0);
+ int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
+
+ if (size < PAGE_SIZE - align) {
+ unsigned int *m;
+ m = slob_alloc(size + align, gfp, align);
if (m)
- m->units = size;
- return m+1;
+ *m = size;
+ return (void *)m + align;
} else {
void *ret;
@@ -449,8 +449,9 @@ void kfree(const void *block)
sp = (struct slob_page *)virt_to_page(block);
if (slob_page(sp)) {
- slob_t *m = (slob_t *)block - 1;
- slob_free(m, m->units + SLOB_UNIT);
+ int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
+ unsigned int *m = (unsigned int *)(block - align);
+ slob_free(m, *m + align);
} else
put_page(&sp->page);
}
@@ -499,6 +500,8 @@ struct kmem_cache *kmem_cache_create(con
c->ctor = ctor;
/* ignore alignment unless it's forced */
c->align = (flags & SLAB_HWCACHE_ALIGN) ? SLOB_ALIGN : 0;
+ if (c->align < ARCH_SLAB_MINALIGN)
+ c->align = ARCH_SLAB_MINALIGN;
if (c->align < align)
c->align = align;
} else if (flags & SLAB_PANIC)
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-22 7:39 [patch 1/3] slob: rework freelist handling Nick Piggin
2007-05-22 7:39 ` [patch 2/3] slob: remove bigblock tracking Nick Piggin
@ 2007-05-22 14:53 ` Matt Mackall
2007-05-22 19:18 ` Christoph Lameter
1 sibling, 1 reply; 66+ messages in thread
From: Matt Mackall @ 2007-05-22 14:53 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 09:39:10AM +0200, Nick Piggin wrote:
> Here are some patches I have been working on for SLOB, which makes
> it significantly faster, and also using less dynamic memory... at
> the cost of being slightly larger static footprint and more complex
> code.
>
> Matt was happy for the first 2 to go into -mm (and hasn't seen patch 3 yet).
These all look good, thanks Nick!
Acked-by: Matt Mackall <mpm@selenic.com>
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-22 14:53 ` [patch 1/3] slob: rework freelist handling Matt Mackall
@ 2007-05-22 19:18 ` Christoph Lameter
2007-05-23 3:06 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-22 19:18 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Tue, 22 May 2007, Matt Mackall wrote:
> On Tue, May 22, 2007 at 09:39:10AM +0200, Nick Piggin wrote:
> > Here are some patches I have been working on for SLOB, which makes
> > it significantly faster, and also using less dynamic memory... at
> > the cost of being slightly larger static footprint and more complex
> > code.
> >
> > Matt was happy for the first 2 to go into -mm (and hasn't seen patch 3 yet).
>
> These all look good, thanks Nick!
>
> Acked-by: Matt Mackall <mpm@selenic.com>
New SLUB inspired life for SLOB. I hope someone else tests this?
Are there any numbers / tests that give a continued reason for the
existence of SLOB? I.e. show some memory usage on a real system that is
actually lower than SLAB/SLUB? Or are there any confirmed platforms where
SLOB is needed?
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-22 19:18 ` Christoph Lameter
@ 2007-05-23 3:06 ` Nick Piggin
2007-05-23 4:55 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 3:06 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 12:18:58PM -0700, Christoph Lameter wrote:
> On Tue, 22 May 2007, Matt Mackall wrote:
>
> > On Tue, May 22, 2007 at 09:39:10AM +0200, Nick Piggin wrote:
> > > Here are some patches I have been working on for SLOB, which makes
> > > it significantly faster, and also using less dynamic memory... at
> > > the cost of being slightly larger static footprint and more complex
> > > code.
> > >
> > > Matt was happy for the first 2 to go into -mm (and hasn't seen patch 3 yet).
> >
> > These all look good, thanks Nick!
> >
> > Acked-by: Matt Mackall <mpm@selenic.com>
>
> New SLUB inspired life for SLOB. I hope someone else tests this?
I'm sure there are people using SLOB, not sure if any of them test the
-mm tree, though. I am planning to get some size comparisons with other
allocators, which shouldn't take long (although I wouldn't know what a
representative tiny setup would look like).
> Are there any numbers / tests that give a continued reason for the
> existence of SLOB? I.e. show some memory usage on a real system that is
> actually lower than SLAB/SLUB? Or are there any confirmed platforms where
> SLOB is needed?
The only real numbers I have off-hand are these
$ size mm/slob.o
text data bss dec hex filename
4160 792 8 4960 1360 mm/slob.o
$ size mm/slub.o
text data bss dec hex filename
11728 6468 176 18372 47c4 mm/slub.o
I'll see if I can get some basic dynamic memory numbers soon. The problem
is that slub oopses on boot on the powerpc platform I'm testing on...
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 3:06 ` Nick Piggin
@ 2007-05-23 4:55 ` Christoph Lameter
2007-05-23 4:59 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 4:55 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> The only real numbers I have off-hand are these
>
> $ size mm/slob.o
> text data bss dec hex filename
> 4160 792 8 4960 1360 mm/slob.o
> $ size mm/slub.o
> text data bss dec hex filename
> 11728 6468 176 18372 47c4 mm/slub.o
Thats with CONFIG_SLUB_DEBUG?
> I'll see if I can get some basic dynamic memory numbers soon. The problem
> is that slub oopses on boot on the powerpc platform I'm testing on...
Please send me a full bug report.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 4:55 ` Christoph Lameter
@ 2007-05-23 4:59 ` Nick Piggin
2007-05-23 5:01 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 4:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 09:55:07PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > The only real numbers I have off-hand are these
> >
> > $ size mm/slob.o
> > text data bss dec hex filename
> > 4160 792 8 4960 1360 mm/slob.o
> > $ size mm/slub.o
> > text data bss dec hex filename
> > 11728 6468 176 18372 47c4 mm/slub.o
>
>
> Thats with CONFIG_SLUB_DEBUG?
No. With CONFIG_SLUB_DEBUG it is more than twice as big again.
> > I'll see if I can get some basic dynamic memory numbers soon. The problem
> > is that slub oopses on boot on the powerpc platform I'm testing on...
>
> Please send me a full bug report.
It was on ppc and there seemed to still be some activity going on
there at the time, so if it still breaks when I retest then I will
send you a report.
Thanks,
Nick
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 4:59 ` Nick Piggin
@ 2007-05-23 5:01 ` Christoph Lameter
2007-05-23 5:03 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 5:01 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> No. With CONFIG_SLUB_DEBUG it is more than twice as big again.
>
>
> > > I'll see if I can get some basic dynamic memory numbers soon. The problem
> > > is that slub oopses on boot on the powerpc platform I'm testing on...
> >
> > Please send me a full bug report.
>
> It was on ppc and there seemed to still be some activity going on
> there at the time, so if it still breaks when I retest then I will
> send you a report.
There is a known issue for !CONFIG_SLUB_DEBUG and 2.6.21-rc1-mm1 and
2.6.22-rc2. Just leave it on.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 5:01 ` Christoph Lameter
@ 2007-05-23 5:03 ` Nick Piggin
2007-05-23 5:06 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 5:03 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 10:01:33PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > No. With CONFIG_SLUB_DEBUG it is more than twice as big again.
> >
> >
> > > > I'll see if I can get some basic dynamic memory numbers soon. The problem
> > > > is that slub oopses on boot on the powerpc platform I'm testing on...
> > >
> > > Please send me a full bug report.
> >
> > It was on ppc and there seemed to still be some activity going on
> > there at the time, so if it still breaks when I retest then I will
> > send you a report.
>
> There is a known issue for !CONFIG_SLUB_DEBUG and 2.6.21-rc1-mm1 and
> 2.6.22-rc2. Just leave it on.
Is there a patch for it? Turning on CONFIG_SLUB_DEBUG doesn't seem like
a good idea when trying to make a comparison.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 5:03 ` Nick Piggin
@ 2007-05-23 5:06 ` Christoph Lameter
2007-05-23 5:11 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 5:06 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> Is there a patch for it? Turning on CONFIG_SLUB_DEBUG doesn't seem like
> a good idea when trying to make a comparison.
CONFIG_SLUB_DEBUG does not turn on debugging and should be on always. This
is not SLAB.
Here is the fix:
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: slub/mm/slub.c
===================================================================
--- slub.orig/mm/slub.c 2007-05-21 11:21:36.000000000 -0700
+++ slub/mm/slub.c 2007-05-21 11:21:49.000000000 -0700
@@ -1943,7 +1943,6 @@ static int calculate_sizes(struct kmem_c
*/
s->inuse = size;
-#ifdef CONFIG_SLUB_DEBUG
if (((flags & (SLAB_DESTROY_BY_RCU | SLAB_POISON)) ||
s->ctor)) {
/*
@@ -1958,6 +1957,7 @@ static int calculate_sizes(struct kmem_c
size += sizeof(void *);
}
+#ifdef CONFIG_SLUB_DEBUG
if (flags & SLAB_STORE_USER)
/*
* Need to store information about allocs and frees after
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 5:06 ` Christoph Lameter
@ 2007-05-23 5:11 ` Nick Piggin
2007-05-23 5:14 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 5:11 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 10:06:56PM -0700, Christoph Lameter wrote:
>
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > Is there a patch for it? Turning on CONFIG_SLUB_DEBUG doesn't seem like
> > a good idea when trying to make a comparison.
>
> CONFIG_SLUB_DEBUG does not turn on debugging and should be on always. This
> is not SLAB.
I don't really know what you mean by this... CONFIG_SLUB_DEBUG adds 20K or
so to the kernel image if nothing else, which just makes a comparison
more difficult. But to me it seems like CONFIG_SLUB_DEBUG also puts extra
redzone in the object sometimes.
> Here is the fix:
Thanks.
>
>
>
> ---
> mm/slub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: slub/mm/slub.c
> ===================================================================
> --- slub.orig/mm/slub.c 2007-05-21 11:21:36.000000000 -0700
> +++ slub/mm/slub.c 2007-05-21 11:21:49.000000000 -0700
> @@ -1943,7 +1943,6 @@ static int calculate_sizes(struct kmem_c
> */
> s->inuse = size;
>
> -#ifdef CONFIG_SLUB_DEBUG
> if (((flags & (SLAB_DESTROY_BY_RCU | SLAB_POISON)) ||
> s->ctor)) {
> /*
> @@ -1958,6 +1957,7 @@ static int calculate_sizes(struct kmem_c
> size += sizeof(void *);
> }
>
> +#ifdef CONFIG_SLUB_DEBUG
> if (flags & SLAB_STORE_USER)
> /*
> * Need to store information about allocs and frees after
>
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 5:11 ` Nick Piggin
@ 2007-05-23 5:14 ` Christoph Lameter
2007-05-23 5:22 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 5:14 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> I don't really know what you mean by this... CONFIG_SLUB_DEBUG adds 20K or
> so to the kernel image if nothing else, which just makes a comparison
> more difficult. But to me it seems like CONFIG_SLUB_DEBUG also puts extra
> redzone in the object sometimes.
CONFIG_SLUB_DEBUG compiles debug code in. It is out of line and activated
if you boot with "slub_debug". If you do not specify "slub_debug" then the
system will run with optimal speed and pack data as tight as possible.
This is intended for distro kernels so that you will not have to rebuild
the kernel for slab debugging if slab corruption occurs.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 5:14 ` Christoph Lameter
@ 2007-05-23 5:22 ` Nick Piggin
2007-05-23 5:28 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 5:22 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 10:14:28PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > I don't really know what you mean by this... CONFIG_SLUB_DEBUG adds 20K or
> > so to the kernel image if nothing else, which just makes a comparison
> > more difficult. But to me it seems like CONFIG_SLUB_DEBUG also puts extra
> > redzone in the object sometimes.
>
> CONFIG_SLUB_DEBUG compiles debug code in. It is out of line and activated
> if you boot with "slub_debug". If you do not specify "slub_debug" then the
> system will run with optimal speed and pack data as tight as possible.
>
> This is intended for distro kernels so that you will not have to rebuild
> the kernel for slab debugging if slab corruption occurs.
OIC, neat. Anyway, the code size issue is still there, so I will
test with the fix instead.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 5:22 ` Nick Piggin
@ 2007-05-23 5:28 ` Christoph Lameter
2007-05-23 6:17 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 5:28 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> > This is intended for distro kernels so that you will not have to rebuild
> > the kernel for slab debugging if slab corruption occurs.
>
> OIC, neat. Anyway, the code size issue is still there, so I will
> test with the fix instead.
A code size issue? You mean SLUB is code wise larger than SLOB?
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 5:28 ` Christoph Lameter
@ 2007-05-23 6:17 ` Nick Piggin
2007-05-23 6:28 ` Christoph Lameter
` (2 more replies)
0 siblings, 3 replies; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 6:17 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 10:28:54PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > > This is intended for distro kernels so that you will not have to rebuild
> > > the kernel for slab debugging if slab corruption occurs.
> >
> > OIC, neat. Anyway, the code size issue is still there, so I will
> > test with the fix instead.
>
> A code size issue? You mean SLUB is code wise larger than SLOB?
That's what the numbers I just posted earlier indicate, yes.
If you want to do a memory consumption shootout with SLOB, you need
all the help you can get ;)
OK, so with a 64-bit UP ppc kernel, compiled for size, and without full
size data structures, booting with mem=16M init=/bin/bash.
2.6.22-rc1-mm1 + your fix + my slob patches.
After booting and mounting /proc, SLOB has 1140K free, SLUB has 748K
free.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 6:17 ` Nick Piggin
@ 2007-05-23 6:28 ` Christoph Lameter
2007-05-23 7:12 ` Nick Piggin
2007-05-23 6:38 ` Christoph Lameter
2007-05-23 7:46 ` Nick Piggin
2 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 6:28 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> If you want to do a memory consumption shootout with SLOB, you need
> all the help you can get ;)
No way. And first you'd have to make SLOB functional. Among other
things it does not support slab reclaim.
> OK, so with a 64-bit UP ppc kernel, compiled for size, and without full
> size data structures, booting with mem=16M init=/bin/bash.
>
> 2.6.22-rc1-mm1 + your fix + my slob patches.
>
> After booting and mounting /proc, SLOB has 1140K free, SLUB has 748K
> free.
Hmm.... Can I see the .config please?
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 6:28 ` Christoph Lameter
@ 2007-05-23 7:12 ` Nick Piggin
2007-05-23 17:03 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 7:12 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 11:28:18PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > If you want to do a memory consumption shootout with SLOB, you need
> > all the help you can get ;)
>
> No way. And first you'd have to make SLOB functional. Among other
> things it does not support slab reclaim.
What do you mean by slab reclaim? SLOB doesn't have slabs and it
never keeps around unused pages so I can't see how it would be able
to do anything more useful. SLOB is fully functional here, on my 4GB
desktop system, even.
The numbers indicate that SLUB would be the one which is not functional
in a tiny memory constrained environment ;)
> > OK, so with a 64-bit UP ppc kernel, compiled for size, and without full
> > size data structures, booting with mem=16M init=/bin/bash.
> >
> > 2.6.22-rc1-mm1 + your fix + my slob patches.
> >
> > After booting and mounting /proc, SLOB has 1140K free, SLUB has 748K
> > free.
>
> Hmm.... Can I see the .config please?
Here is the one I used for SLOB (SLUB is otherwise the same, and
without SLOB_DEBUG). BTW, the system booted fine with SLUB and the
fix you sent.
--
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc1-mm1-slob
# Sat May 19 15:29:39 2007
#
CONFIG_PPC64=y
CONFIG_PPC_PM_NEEDS_RTC_LIB=y
CONFIG_64BIT=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
# CONFIG_PPC_UDBG_16550 is not set
CONFIG_GENERIC_TBSYNC=y
CONFIG_AUDIT_ARCH=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_PPC64_SWSUSP=y
#
# Processor support
#
CONFIG_POWER4_ONLY=y
CONFIG_POWER4=y
CONFIG_PPC_FPU=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_MM_SLICES=y
CONFIG_VIRT_CPU_ACCOUNTING=y
# CONFIG_SMP is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
# CONFIG_SWAP_PREFETCH is not set
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_KALLSYMS is not set
# CONFIG_HOTPLUG is not set
CONFIG_PRINTK=y
# CONFIG_BUG is not set
CONFIG_ELF_CORE=y
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
# CONFIG_ANON_INODES is not set
# CONFIG_SHMEM is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
# CONFIG_PROC_SMAPS is not set
# CONFIG_PROC_CLEAR_REFS is not set
# CONFIG_PROC_PAGEMAP is not set
# CONFIG_PROC_KPAGEMAP is not set
CONFIG_RT_MUTEXES=y
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=1
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_EMBEDDED6xx is not set
# CONFIG_APUS is not set
# CONFIG_PPC_PSERIES is not set
# CONFIG_PPC_ISERIES is not set
# CONFIG_PPC_MPC52xx is not set
# CONFIG_PPC_MPC5200 is not set
CONFIG_PPC_PMAC=y
CONFIG_PPC_PMAC64=y
# CONFIG_PPC_MAPLE is not set
# CONFIG_PPC_PASEMI is not set
# CONFIG_PPC_CELLEB is not set
# CONFIG_PPC_PS3 is not set
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PPC_IBM_CELL_BLADE is not set
# CONFIG_PQ2ADS is not set
CONFIG_PPC_NATIVE=y
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
CONFIG_U3_DART=y
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
CONFIG_MPIC_U3_HT_IRQS=y
# CONFIG_PPC_MPC106 is not set
CONFIG_PPC_970_NAP=y
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
#
# CPU Frequency drivers
#
CONFIG_CPU_FREQ_PMAC64=y
# CONFIG_CPM2 is not set
#
# Kernel options
#
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_IOMMU_VMERGE=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_NUMA is not set
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
# CONFIG_PPC_HAS_HASH_64K is not set
# CONFIG_PPC_64K_PAGES is not set
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
# CONFIG_SOFTWARE_SUSPEND is not set
# CONFIG_SECCOMP is not set
# CONFIG_WANT_DEVICE_TREE is not set
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PPC_INDIRECT_PCI is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_KERNEL_START=0xc000000000000000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_CDROM_PKTCDVD_WCACHE=y
# CONFIG_ATA_OVER_ETH is not set
CONFIG_MISC_STRANGE_DEV=y
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_BLINK is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_IDE=m
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=m
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_IDEDISK=m
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_IDEPCI_PCIBUS_ORDER is not set
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=m
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SL82C105 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_ESP_CORE is not set
# CONFIG_SCSI_SRP is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_SATA_AHCI is not set
CONFIG_SATA_SVW=y
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
CONFIG_IEEE1394_SUPPORT=y
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_ADB_PMU=y
# CONFIG_ADB_PMU_LED is not set
CONFIG_PMAC_SMU=y
# CONFIG_PMAC_APM_EMU is not set
# CONFIG_MAC_EMUMOUSEBTN is not set
CONFIG_THERM_PM72=y
CONFIG_WINDFARM=y
CONFIG_WINDFARM_PM81=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
# CONFIG_PMAC_RACKMETER is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
CONFIG_BROADCOM_PHY=m
# CONFIG_FIXED_PHY is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
CONFIG_SUNGEM=y
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_NET_PCI is not set
# CONFIG_B44 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
CONFIG_TIGON3=y
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_RTL818X is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_PMACZILOG is not set
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_GEN_RTC=y
CONFIG_GEN_RTC_X=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
CONFIG_AGP=m
CONFIG_AGP_UNINORTH=m
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_POWERMAC=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=m
#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y
#
# Display hardware drivers
#
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
CONFIG_FB_MACMODES=y
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
CONFIG_FB_OF=y
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
# CONFIG_SND_SEQUENCER_OSS is not set
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_GENERIC_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PCI_DRIVERS=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_PPC_DRIVERS=y
# CONFIG_SND_POWERMAC is not set
CONFIG_SND_AOA=m
CONFIG_SND_AOA_FABRIC_LAYOUT=m
CONFIG_SND_AOA_ONYX=m
CONFIG_SND_AOA_TAS=m
CONFIG_SND_AOA_TOONIE=m
CONFIG_SND_AOA_SOUNDBUS=m
CONFIG_SND_AOA_SOUNDBUS_I2S=m
# CONFIG_SND_USB_DRIVERS is not set
# CONFIG_SND_SOC_DRIVERS is not set
# CONFIG_SOUND_PRIME is not set
#
# HID Devices
#
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
CONFIG_HIDRAW=y
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PPC_OF=y
CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
# CONFIG_USB_OHCI_HCD_PPC_OF_LE is not set
CONFIG_USB_OHCI_HCD_PCI=y
CONFIG_USB_OHCI_BIG_ENDIAN_DESC=y
CONFIG_USB_OHCI_BIG_ENDIAN_MMIO=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_MON is not set
#
# USB port drivers
#
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
CONFIG_USB_APPLEDISPLAY=y
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GOTEMP is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
#
# Real Time Clock
#
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set
#
# DMA Clients
#
# CONFIG_ASYNC_TX_DMA is not set
#
# DMA Devices
#
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set
#
# Layered filesystems
#
# CONFIG_UNION_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_BIND34 is not set
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
#
# Native Language Support
#
CONFIG_NLS=m
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m
#
# Distributed Lock Manager
#
# CONFIG_DLM is not set
# CONFIG_UCC_SLOW is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_LZO is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_PROFILE_LIKELY is not set
CONFIG_IRQSTACKS=y
CONFIG_BOOTX_TEXT=y
# CONFIG_PPC_EARLY_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_INTEGRITY is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ABLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_XCBC=m
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_GF128MUL=m
# CONFIG_CRYPTO_ECB is not set
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_HW is not set
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 7:12 ` Nick Piggin
@ 2007-05-23 17:03 ` Christoph Lameter
2007-05-23 18:32 ` Matt Mackall
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 17:03 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> On Tue, May 22, 2007 at 11:28:18PM -0700, Christoph Lameter wrote:
> > On Wed, 23 May 2007, Nick Piggin wrote:
> >
> > > If you want to do a memory consumption shootout with SLOB, you need
> > > all the help you can get ;)
> >
> > No way. And first you'd have to make SLOB functional. Among other
> > things it does not support slab reclaim.
>
> What do you mean by slab reclaim? SLOB doesn't have slabs and it
> never keeps around unused pages so I can't see how it would be able
> to do anything more useful. SLOB is fully functional here, on my 4GB
> desktop system, even.
SLOB does not f.e. handle the SLAB ZVCs. The VM will think there is no
slab use and never shrink the slabs.
> The numbers indicate that SLUB would be the one which is not functional
> in a tiny memory constrained environment ;)
Well, apart from the red herring: That is likely an issue of properly
configuring the system and slowing down the allocator by not keeping
too much memory in its queues. If we do not consider the code size issues:
How much memory are we talking about?
What is the page size? We likely have one potentially empty cpu slab
for each of the 50 or so slabs used during boot. This is already 200k
given a 4K page size. That could be released by shrinking and if you just
run bash the most of them are not going to be used anyways.
> > Hmm.... Can I see the .config please?
>
> Here is the one I used for SLOB (SLUB is otherwise the same, and
> without SLOB_DEBUG). BTW, the system booted fine with SLUB and the
> fix you sent.
Looks fine to me.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 17:03 ` Christoph Lameter
@ 2007-05-23 18:32 ` Matt Mackall
2007-05-23 19:15 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Matt Mackall @ 2007-05-23 18:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 10:03:34AM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > On Tue, May 22, 2007 at 11:28:18PM -0700, Christoph Lameter wrote:
> > > On Wed, 23 May 2007, Nick Piggin wrote:
> > >
> > > > If you want to do a memory consumption shootout with SLOB, you need
> > > > all the help you can get ;)
> > >
> > > No way. And first you'd have to make SLOB functional. Among other
> > > things it does not support slab reclaim.
> >
> > What do you mean by slab reclaim? SLOB doesn't have slabs and it
> > never keeps around unused pages so I can't see how it would be able
> > to do anything more useful. SLOB is fully functional here, on my 4GB
> > desktop system, even.
>
> SLOB does not f.e. handle the SLAB ZVCs. The VM will think there is no
> slab use and never shrink the slabs.
You keep saying something like this but I'm never quite clear what you
mean. There are no slabs so reclaiming unused slabs is a non-issue.
Things like shrinking the dcache should work:
__alloc_pages
try_to_free_pages
shrink_slab
shrink_dcache_memory
I don't see any checks of ZVCs interfering with that path.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 18:32 ` Matt Mackall
@ 2007-05-23 19:15 ` Christoph Lameter
2007-05-23 19:58 ` Matt Mackall
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 19:15 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Matt Mackall wrote:
> You keep saying something like this but I'm never quite clear what you
> mean. There are no slabs so reclaiming unused slabs is a non-issue.
> Things like shrinking the dcache should work:
>
> __alloc_pages
> try_to_free_pages
> shrink_slab
> shrink_dcache_memory
>
> I don't see any checks of ZVCs interfering with that path.
One example is the NR_SLAB_RECLAIMABLE ZVC. SLOB does not handle it thus
it is always zero.
slab reclaim is entered in mm/vsmscan shrink_all_memory():
nr_slab = global_page_state(NR_SLAB_RECLAIMABLE);
/* If slab caches are huge, it's better to hit them first */
while (nr_slab >= lru_pages) {
reclaim_state.reclaimed_slab = 0;
shrink_slab(nr_pages, sc.gfp_mask, lru_pages);
if (!reclaim_state.reclaimed_slab)
nr_slab will always be zero.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 19:15 ` Christoph Lameter
@ 2007-05-23 19:58 ` Matt Mackall
2007-05-23 20:02 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Matt Mackall @ 2007-05-23 19:58 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 12:15:16PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Matt Mackall wrote:
>
> > You keep saying something like this but I'm never quite clear what you
> > mean. There are no slabs so reclaiming unused slabs is a non-issue.
> > Things like shrinking the dcache should work:
> >
> > __alloc_pages
> > try_to_free_pages
> > shrink_slab
> > shrink_dcache_memory
> >
> > I don't see any checks of ZVCs interfering with that path.
>
> One example is the NR_SLAB_RECLAIMABLE ZVC. SLOB does not handle it thus
> it is always zero.
>
> slab reclaim is entered in mm/vsmscan shrink_all_memory():
>
> nr_slab = global_page_state(NR_SLAB_RECLAIMABLE);
> /* If slab caches are huge, it's better to hit them first */
> while (nr_slab >= lru_pages) {
> reclaim_state.reclaimed_slab = 0;
> shrink_slab(nr_pages, sc.gfp_mask, lru_pages);
> if (!reclaim_state.reclaimed_slab)
>
>
> nr_slab will always be zero.
That's line 1448, but won't we hit that again unconditionally at 1485?
And again at 1503?
Meanwhile this function is only called from swsusp.c.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 19:58 ` Matt Mackall
@ 2007-05-23 20:02 ` Christoph Lameter
2007-05-23 20:16 ` Christoph Lameter
2007-05-23 21:06 ` Matt Mackall
0 siblings, 2 replies; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 20:02 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Matt Mackall wrote:
> Meanwhile this function is only called from swsusp.c.
NR_SLAB_UNRECLAIMABLE is also used in __vm_enough_memory and
in zone reclaim (well ok thats only NUMA).
Plus the SLAB sizes are not reported to user space. We see 0 in
/proc/meminfo etc etc.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 20:02 ` Christoph Lameter
@ 2007-05-23 20:16 ` Christoph Lameter
2007-05-23 21:14 ` Matt Mackall
2007-05-23 21:06 ` Matt Mackall
1 sibling, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 20:16 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
Oh. And I forgot to check mm.
See swap_prefetch.c:prefetch_suitable
I do not think the updating of these counters is optional. Their use will
increase as we get more sophisticated in balancing the VM load. We cannot
have developers do an #ifdef CONFIG_SLOB around ZVC use.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 20:16 ` Christoph Lameter
@ 2007-05-23 21:14 ` Matt Mackall
0 siblings, 0 replies; 66+ messages in thread
From: Matt Mackall @ 2007-05-23 21:14 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 01:16:06PM -0700, Christoph Lameter wrote:
> Oh. And I forgot to check mm.
>
> See swap_prefetch.c:prefetch_suitable
Doesn't look problematic to me. Or if it is, it'll die for any system
that happens to use get_free_page a lot.
> I do not think the updating of these counters is optional. Their use will
> increase as we get more sophisticated in balancing the VM load. We cannot
> have developers do an #ifdef CONFIG_SLOB around ZVC use.
How does the VM deal with balancing users of get_free_page?
We can probably add a couple lines to dummy up NR_SLAB_UNRECLAIMABLE, but I
think the claim that SLOB is "broken" without it is completely overblown.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 20:02 ` Christoph Lameter
2007-05-23 20:16 ` Christoph Lameter
@ 2007-05-23 21:06 ` Matt Mackall
2007-05-23 22:26 ` Christoph Lameter
1 sibling, 1 reply; 66+ messages in thread
From: Matt Mackall @ 2007-05-23 21:06 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 01:02:53PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Matt Mackall wrote:
>
> > Meanwhile this function is only called from swsusp.c.
>
> NR_SLAB_UNRECLAIMABLE is also used in __vm_enough_memory and
> in zone reclaim (well ok thats only NUMA).
It's NR_SLAB_RECLAIMABLE in __vm_enough_memory. And that is always
zero with SLOB. There aren't any reclaimable slab pages.
SLOB does do UNRECLAIMABLE, true. But there aren't any interesting
users of SLAB_UNRECLAIMABLE that I can see.
> Plus the SLAB sizes are not reported to user space. We see 0 in
> /proc/meminfo etc etc.
That's because there are no slabs! Memory usage shows up here in
exactly the same way that memory usage from get_free_page does.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 21:06 ` Matt Mackall
@ 2007-05-23 22:26 ` Christoph Lameter
2007-05-23 22:42 ` Matt Mackall
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 22:26 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Matt Mackall wrote:
> On Wed, May 23, 2007 at 01:02:53PM -0700, Christoph Lameter wrote:
> > On Wed, 23 May 2007, Matt Mackall wrote:
> >
> > > Meanwhile this function is only called from swsusp.c.
> >
> > NR_SLAB_UNRECLAIMABLE is also used in __vm_enough_memory and
> > in zone reclaim (well ok thats only NUMA).
>
> It's NR_SLAB_RECLAIMABLE in __vm_enough_memory. And that is always
> zero with SLOB. There aren't any reclaimable slab pages.
All dentries and inodes are reclaimable via the shrinkers in vmscan.c. So
you are saying that SLOB does not allow dentry and inode reclaim?
> SLOB does do UNRECLAIMABLE, true. But there aren't any interesting
> users of SLAB_UNRECLAIMABLE that I can see.
> That's because there are no slabs! Memory usage shows up here in
> exactly the same way that memory usage from get_free_page does.
So there seems to be a basic unresolvable issue with SLOB....
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 22:26 ` Christoph Lameter
@ 2007-05-23 22:42 ` Matt Mackall
2007-05-23 22:48 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Matt Mackall @ 2007-05-23 22:42 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 03:26:05PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Matt Mackall wrote:
>
> > On Wed, May 23, 2007 at 01:02:53PM -0700, Christoph Lameter wrote:
> > > On Wed, 23 May 2007, Matt Mackall wrote:
> > >
> > > > Meanwhile this function is only called from swsusp.c.
> > >
> > > NR_SLAB_UNRECLAIMABLE is also used in __vm_enough_memory and
> > > in zone reclaim (well ok thats only NUMA).
> >
> > It's NR_SLAB_RECLAIMABLE in __vm_enough_memory. And that is always
> > zero with SLOB. There aren't any reclaimable slab pages.
>
> All dentries and inodes are reclaimable via the shrinkers in vmscan.c. So
> you are saying that SLOB does not allow dentry and inode reclaim?
No. I've already pointed out the EXACT CALL CHAIN that leads to dentry
reclaim. And it's independent of NR_SLAB_RECLAIMABLE and independent
of allocator.
> > SLOB does do UNRECLAIMABLE, true. But there aren't any interesting
> > users of SLAB_UNRECLAIMABLE that I can see.
>
> > That's because there are no slabs! Memory usage shows up here in
> > exactly the same way that memory usage from get_free_page does.
>
> So there seems to be a basic unresolvable issue with SLOB....
Already responded to this one too.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 22:42 ` Matt Mackall
@ 2007-05-23 22:48 ` Christoph Lameter
2007-05-24 2:05 ` Nick Piggin
2007-05-24 6:11 ` Matt Mackall
0 siblings, 2 replies; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 22:48 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Matt Mackall wrote:
> On Wed, May 23, 2007 at 03:26:05PM -0700, Christoph Lameter wrote:
> > On Wed, 23 May 2007, Matt Mackall wrote:
> >
> > > On Wed, May 23, 2007 at 01:02:53PM -0700, Christoph Lameter wrote:
> > > > On Wed, 23 May 2007, Matt Mackall wrote:
> > > >
> > > > > Meanwhile this function is only called from swsusp.c.
> > > >
> > > > NR_SLAB_UNRECLAIMABLE is also used in __vm_enough_memory and
> > > > in zone reclaim (well ok thats only NUMA).
> > >
> > > It's NR_SLAB_RECLAIMABLE in __vm_enough_memory. And that is always
> > > zero with SLOB. There aren't any reclaimable slab pages.
> >
> > All dentries and inodes are reclaimable via the shrinkers in vmscan.c. So
> > you are saying that SLOB does not allow dentry and inode reclaim?
>
> No. I've already pointed out the EXACT CALL CHAIN that leads to dentry
> reclaim. And it's independent of NR_SLAB_RECLAIMABLE and independent
> of allocator.
So we have an allocator which is not following the rules... You are
arguing that dysfunctional behavior of SLOB does not have bad effects.
1. We have allocated reclaimable objects via SLOB (dentry & inodes)
2. We can reclaim them
3. The allocator lies about it telling the VM that there is nothing
reclaimable because NR_SLAB_UNRECLAIMABLE is always 0.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 22:48 ` Christoph Lameter
@ 2007-05-24 2:05 ` Nick Piggin
2007-05-24 2:45 ` Christoph Lameter
2007-05-24 2:49 ` Christoph Lameter
2007-05-24 6:11 ` Matt Mackall
1 sibling, 2 replies; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 2:05 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 03:48:18PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Matt Mackall wrote:
>
> > On Wed, May 23, 2007 at 03:26:05PM -0700, Christoph Lameter wrote:
> > > On Wed, 23 May 2007, Matt Mackall wrote:
> > >
> > > > On Wed, May 23, 2007 at 01:02:53PM -0700, Christoph Lameter wrote:
> > > > > On Wed, 23 May 2007, Matt Mackall wrote:
> > > > >
> > > > > > Meanwhile this function is only called from swsusp.c.
> > > > >
> > > > > NR_SLAB_UNRECLAIMABLE is also used in __vm_enough_memory and
> > > > > in zone reclaim (well ok thats only NUMA).
> > > >
> > > > It's NR_SLAB_RECLAIMABLE in __vm_enough_memory. And that is always
> > > > zero with SLOB. There aren't any reclaimable slab pages.
> > >
> > > All dentries and inodes are reclaimable via the shrinkers in vmscan.c. So
> > > you are saying that SLOB does not allow dentry and inode reclaim?
> >
> > No. I've already pointed out the EXACT CALL CHAIN that leads to dentry
> > reclaim. And it's independent of NR_SLAB_RECLAIMABLE and independent
> > of allocator.
>
> So we have an allocator which is not following the rules... You are
> arguing that dysfunctional behavior of SLOB does not have bad effects.
>
> 1. We have allocated reclaimable objects via SLOB (dentry & inodes)
>
> 2. We can reclaim them
>
> 3. The allocator lies about it telling the VM that there is nothing
> reclaimable because NR_SLAB_UNRECLAIMABLE is always 0.
SLOB doesn't keep track of what pages might be reclaimable, so yes
it reports zero to the VM. That doesn't make it non functional or
even prevent slab reclaim from working.
Doesn't SLUB "lie" to the VM telling it that unreclaimable dentries
are reclaimable? That doesn't make it broken...
If you were to come up with a system that gets the accounting right
while also being as space efficient, then sure that is preferable.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 2:05 ` Nick Piggin
@ 2007-05-24 2:45 ` Christoph Lameter
2007-05-24 2:47 ` Nick Piggin
2007-05-24 2:49 ` Christoph Lameter
1 sibling, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 2:45 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Nick Piggin wrote:
> SLOB doesn't keep track of what pages might be reclaimable, so yes
> it reports zero to the VM. That doesn't make it non functional or
> even prevent slab reclaim from working.
It does make the counters useless. The VM activities that depend on these
will not work.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 2:45 ` Christoph Lameter
@ 2007-05-24 2:47 ` Nick Piggin
2007-05-24 2:55 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 2:47 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 07:45:37PM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Nick Piggin wrote:
>
> > SLOB doesn't keep track of what pages might be reclaimable, so yes
> > it reports zero to the VM. That doesn't make it non functional or
> > even prevent slab reclaim from working.
>
> It does make the counters useless. The VM activities that depend on these
> will not work.
Sure some things may be suboptimal, but the VM cannot just fall over
and become non-functional if there is no reclaimable slab, surely?
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 2:47 ` Nick Piggin
@ 2007-05-24 2:55 ` Christoph Lameter
2007-05-24 3:17 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 2:55 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Nick Piggin wrote:
> Sure some things may be suboptimal, but the VM cannot just fall over
> and become non-functional if there is no reclaimable slab, surely?
The check in __vm_enough_memory in particular is worrying there.
Overcommit may not work right. If large caches are created via SLOB then
we may OOM.
Of course one can dismiss this by saying that the conditions under which
this is true are rare etc etc.
Similarly the breakage of software suspend also did not matter..
Then swap prefetch (also using slab ZVCs) probably also does not matter.
Guess embedded systems just have to be careful what kernel features they
use and over time they can use less....
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 2:55 ` Christoph Lameter
@ 2007-05-24 3:17 ` Nick Piggin
0 siblings, 0 replies; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 3:17 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 07:55:56PM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Nick Piggin wrote:
>
> > Sure some things may be suboptimal, but the VM cannot just fall over
> > and become non-functional if there is no reclaimable slab, surely?
>
> The check in __vm_enough_memory in particular is worrying there.
> Overcommit may not work right. If large caches are created via SLOB then
> we may OOM.
On the other hand, if I enabled overcommit on an embedded system, then I
might prefer not to call any slab memory reclaimable because you don't
actually know if it is able to be reclaimed anyway.
> Of course one can dismiss this by saying that the conditions under which
> this is true are rare etc etc.
>
> Similarly the breakage of software suspend also did not matter..
>
> Then swap prefetch (also using slab ZVCs) probably also does not matter.
>
> Guess embedded systems just have to be careful what kernel features they
> use and over time they can use less....
Anyway, this is just going around in circles, because the embedded
people using SLOB actually use it for the feature that it very memory
efficient, which is something the other allocators do not have. But
you just keep dismissing that...
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 2:05 ` Nick Piggin
2007-05-24 2:45 ` Christoph Lameter
@ 2007-05-24 2:49 ` Christoph Lameter
2007-05-24 3:15 ` Nick Piggin
1 sibling, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 2:49 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
Here is what I got trying to trim down SLUB on x84_64 (UP config)
Full:
text data bss dec hex filename
25928 11351 256 37535 929f mm/slub.o
!CONFIG_SLUB_DEBUG + patch below
text data bss dec hex filename
8639 4735 224 13598 351e mm/slub.o
SLOB
text data bss dec hex filename
4206 96 0 4302 10ce mm/slob.o
So we can get down to about double the text size. Data is of course an
issue. Other 64 bit platforms bloat the code significantly.
Interesting that inlining some functions actually saves memory.
SLUB embedded: Reduce memory use II
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
include/linux/slub_def.h | 4 +++
mm/slub.c | 49 ++++++++++++++++++++++++++++++++---------------
2 files changed, 38 insertions(+), 15 deletions(-)
Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h 2007-05-23 19:34:50.000000000 -0700
+++ slub/include/linux/slub_def.h 2007-05-23 19:35:12.000000000 -0700
@@ -17,7 +17,9 @@ struct kmem_cache_node {
unsigned long nr_partial;
atomic_long_t nr_slabs;
struct list_head partial;
+#ifdef CONFIG_SLUB_DEBUG
struct list_head full;
+#endif
};
/*
@@ -45,7 +47,9 @@ struct kmem_cache {
int align; /* Alignment */
const char *name; /* Name (only for display!) */
struct list_head list; /* List of slab caches */
+#ifdef CONFIG_SLUB_DEBUG
struct kobject kobj; /* For sysfs */
+#endif
#ifdef CONFIG_NUMA
int defrag_ratio;
Index: slub/mm/slub.c
===================================================================
--- slub.orig/mm/slub.c 2007-05-23 19:34:50.000000000 -0700
+++ slub/mm/slub.c 2007-05-23 19:35:12.000000000 -0700
@@ -183,7 +183,11 @@ static inline void ClearSlabDebug(struct
* Mininum number of partial slabs. These will be left on the partial
* lists even if they are empty. kmem_cache_shrink may reclaim them.
*/
+#ifdef CONFIG_SLUB_DEBUG
#define MIN_PARTIAL 2
+#else
+#define MIN_PARTIAL 0
+#endif
/*
* Maximum number of desirable partial slabs.
@@ -254,9 +258,9 @@ static int sysfs_slab_add(struct kmem_ca
static int sysfs_slab_alias(struct kmem_cache *, const char *);
static void sysfs_slab_remove(struct kmem_cache *);
#else
-static int sysfs_slab_add(struct kmem_cache *s) { return 0; }
-static int sysfs_slab_alias(struct kmem_cache *s, const char *p) { return 0; }
-static void sysfs_slab_remove(struct kmem_cache *s) {}
+static inline int sysfs_slab_add(struct kmem_cache *s) { return 0; }
+static inline int sysfs_slab_alias(struct kmem_cache *s, const char *p) { return 0; }
+static inline void sysfs_slab_remove(struct kmem_cache *s) {}
#endif
/********************************************************************
@@ -1011,7 +1015,7 @@ static struct page *allocate_slab(struct
return page;
}
-static void setup_object(struct kmem_cache *s, struct page *page,
+static inline void setup_object(struct kmem_cache *s, struct page *page,
void *object)
{
setup_object_debug(s, page, object);
@@ -1346,7 +1350,7 @@ static void deactivate_slab(struct kmem_
unfreeze_slab(s, page);
}
-static void flush_slab(struct kmem_cache *s, struct page *page, int cpu)
+static inline void flush_slab(struct kmem_cache *s, struct page *page, int cpu)
{
slab_lock(page);
deactivate_slab(s, page, cpu);
@@ -1356,7 +1360,7 @@ static void flush_slab(struct kmem_cache
* Flush cpu slab.
* Called from IPI handler with interrupts disabled.
*/
-static void __flush_cpu_slab(struct kmem_cache *s, int cpu)
+static inline void __flush_cpu_slab(struct kmem_cache *s, int cpu)
{
struct page *page = s->cpu_slab[cpu];
@@ -1490,7 +1494,7 @@ debug:
*
* Otherwise we can simply pick the next object from the lockless free list.
*/
-static void __always_inline *slab_alloc(struct kmem_cache *s,
+static void *slab_alloc(struct kmem_cache *s,
gfp_t gfpflags, int node, void *addr)
{
struct page *page;
@@ -1595,7 +1599,7 @@ debug:
* If fastpath is not possible then fall back to __slab_free where we deal
* with all sorts of special processing.
*/
-static void __always_inline slab_free(struct kmem_cache *s,
+static void slab_free(struct kmem_cache *s,
struct page *page, void *x, void *addr)
{
void **object = (void *)x;
@@ -1764,7 +1768,7 @@ static inline int calculate_order(int si
/*
* Figure out what the alignment of the objects will be.
*/
-static unsigned long calculate_alignment(unsigned long flags,
+static inline unsigned long calculate_alignment(unsigned long flags,
unsigned long align, unsigned long size)
{
/*
@@ -1786,13 +1790,15 @@ static unsigned long calculate_alignment
return ALIGN(align, sizeof(void *));
}
-static void init_kmem_cache_node(struct kmem_cache_node *n)
+static inline void init_kmem_cache_node(struct kmem_cache_node *n)
{
n->nr_partial = 0;
atomic_long_set(&n->nr_slabs, 0);
spin_lock_init(&n->list_lock);
INIT_LIST_HEAD(&n->partial);
+#ifdef CONFIG_SLUB_DEBUG
INIT_LIST_HEAD(&n->full);
+#endif
}
#ifdef CONFIG_NUMA
@@ -1877,11 +1883,11 @@ static int init_kmem_cache_nodes(struct
return 1;
}
#else
-static void free_kmem_cache_nodes(struct kmem_cache *s)
+static inline void free_kmem_cache_nodes(struct kmem_cache *s)
{
}
-static int init_kmem_cache_nodes(struct kmem_cache *s, gfp_t gfpflags)
+static inline int init_kmem_cache_nodes(struct kmem_cache *s, gfp_t gfpflags)
{
init_kmem_cache_node(&s->local_node);
return 1;
@@ -2278,8 +2284,9 @@ size_t ksize(const void *object)
BUG_ON(!page);
s = page->slab;
- BUG_ON(!s);
+#ifdef CONFIG_SLUB_DEBUG
+ BUG_ON(!s);
/*
* Debugging requires use of the padding between object
* and whatever may come after it.
@@ -2295,6 +2302,8 @@ size_t ksize(const void *object)
if (s->flags & (SLAB_DESTROY_BY_RCU | SLAB_STORE_USER))
return s->inuse;
+#endif
+
/*
* Else we can use all the padding etc for the allocation
*/
@@ -2329,6 +2338,7 @@ EXPORT_SYMBOL(kfree);
*/
int kmem_cache_shrink(struct kmem_cache *s)
{
+#ifdef CONFIG_SLUB_DEBUG
int node;
int i;
struct kmem_cache_node *n;
@@ -2392,6 +2402,9 @@ int kmem_cache_shrink(struct kmem_cache
}
kfree(slabs_by_inuse);
+#else
+ flush_all(s);
+#endif
return 0;
}
EXPORT_SYMBOL(kmem_cache_shrink);
@@ -2475,10 +2488,12 @@ void __init kmem_cache_init(void)
slab_state = UP;
+#ifdef CONFIG_SLUB_DEBUG
/* Provide the correct kmalloc names now that the caches are up */
for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++)
kmalloc_caches[i]. name =
kasprintf(GFP_KERNEL, "kmalloc-%d", 1 << i);
+#endif
#ifdef CONFIG_SMP
register_cpu_notifier(&slab_notifier);
@@ -3659,17 +3674,20 @@ static int sysfs_slab_alias(struct kmem_
return 0;
}
+#endif
static int __init slab_sysfs_init(void)
{
struct list_head *h;
int err;
+#ifdef CONFIG_SLUB_DEBUG
err = subsystem_register(&slab_subsys);
if (err) {
printk(KERN_ERR "Cannot register slab subsystem.\n");
return -ENOSYS;
}
+#endif
slab_state = SYSFS;
list_for_each(h, &slab_caches) {
@@ -3678,8 +3696,10 @@ static int __init slab_sysfs_init(void)
err = sysfs_slab_add(s);
BUG_ON(err);
+ kmem_cache_shrink(s);
}
+#ifdef CONFIG_SLUB_DEBUG
while (alias_list) {
struct saved_alias *al = alias_list;
@@ -3690,8 +3710,7 @@ static int __init slab_sysfs_init(void)
}
resiliency_test();
+#endif
return 0;
}
-
__initcall(slab_sysfs_init);
-#endif
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 2:49 ` Christoph Lameter
@ 2007-05-24 3:15 ` Nick Piggin
2007-05-24 3:51 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 3:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 07:49:50PM -0700, Christoph Lameter wrote:
> Here is what I got trying to trim down SLUB on x84_64 (UP config)
>
> Full:
>
> text data bss dec hex filename
> 25928 11351 256 37535 929f mm/slub.o
>
> !CONFIG_SLUB_DEBUG + patch below
>
> text data bss dec hex filename
> 8639 4735 224 13598 351e mm/slub.o
>
> SLOB
>
> text data bss dec hex filename
> 4206 96 0 4302 10ce mm/slob.o
>
> So we can get down to about double the text size. Data is of course an
> issue. Other 64 bit platforms bloat the code significantly.
>
> Interesting that inlining some functions actually saves memory.
>
> SLUB embedded: Reduce memory use II
After boot test, this has 760K free.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 3:15 ` Nick Piggin
@ 2007-05-24 3:51 ` Christoph Lameter
0 siblings, 0 replies; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 3:51 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Nick Piggin wrote:
> > SLUB embedded: Reduce memory use II
>
> After boot test, this has 760K free.
Tss. What is this? No code reduction? The inlining was probably only
useful on x86_64 and a drawback on PPC.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 22:48 ` Christoph Lameter
2007-05-24 2:05 ` Nick Piggin
@ 2007-05-24 6:11 ` Matt Mackall
2007-05-24 16:36 ` Christoph Lameter
1 sibling, 1 reply; 66+ messages in thread
From: Matt Mackall @ 2007-05-24 6:11 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 03:48:18PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Matt Mackall wrote:
>
> > On Wed, May 23, 2007 at 03:26:05PM -0700, Christoph Lameter wrote:
> > > On Wed, 23 May 2007, Matt Mackall wrote:
> > >
> > > > On Wed, May 23, 2007 at 01:02:53PM -0700, Christoph Lameter wrote:
> > > > > On Wed, 23 May 2007, Matt Mackall wrote:
> > > > >
> > > > > > Meanwhile this function is only called from swsusp.c.
> > > > >
> > > > > NR_SLAB_UNRECLAIMABLE is also used in __vm_enough_memory and
> > > > > in zone reclaim (well ok thats only NUMA).
> > > >
> > > > It's NR_SLAB_RECLAIMABLE in __vm_enough_memory. And that is always
> > > > zero with SLOB. There aren't any reclaimable slab pages.
> > >
> > > All dentries and inodes are reclaimable via the shrinkers in vmscan.c. So
> > > you are saying that SLOB does not allow dentry and inode reclaim?
> >
> > No. I've already pointed out the EXACT CALL CHAIN that leads to dentry
> > reclaim. And it's independent of NR_SLAB_RECLAIMABLE and independent
> > of allocator.
>
> So we have an allocator which is not following the rules... You are
> arguing that dysfunctional behavior of SLOB does not have bad effects.
>
> 1. We have allocated reclaimable objects via SLOB (dentry & inodes)
>
> 2. We can reclaim them
>
> 3. The allocator lies about it telling the VM that there is nothing
> reclaimable because NR_SLAB_UNRECLAIMABLE is always 0.
4. The VM calls shrink_slabs anyway so the implied "rules" don't
actually exist (yet).
Because there's no guarantee that dcache or icache can actually be
shrunk _at all_, the VM can't do much of anything with
NR_SLAB_RECLAIMABLE. It could skip shrinking slabs if RECLAIMABLE=0
but as that never happens in practice with SLAB, the check's pretty
pointless. Nor can users glean any information from it, in fact
they'll probably be mislead!
So, here's three possible approaches to this issue:
A) Continue to ignore it. Doing something about it would add
complexity and it's not clear that it's a win.
B) Set NR_SLAB_RECLAIMABLE to 1. If the VM starts checking that to
decide whether it should call shrinkers, things will continue to work.
Increment and decrement NR_SLAB_UNRECLAIMABLE when we grow/shrink the
SLOB pool. This is probably 3 lines of code total.
C) Fake NR_SLAB_RECLAIMABLE/NR_SLAB_UNRECLAIMABLE based on actual
allocs and slab flags such that they sum to the total pages in the
SLOB pool. This would need a third global counter in bytes of how many
allocs we had in the "reclaimable" slabs. Probably 10-20 lines of
code of marginal utility.
So, nothing insurmountable here. Just not convinced we should bother.
But the cost of B is so low, perhaps I might as well.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 6:11 ` Matt Mackall
@ 2007-05-24 16:36 ` Christoph Lameter
2007-05-24 17:22 ` Matt Mackall
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 16:36 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Matt Mackall wrote:
> So, here's three possible approaches to this issue:
>
> A) Continue to ignore it. Doing something about it would add
> complexity and it's not clear that it's a win.
>
> B) Set NR_SLAB_RECLAIMABLE to 1. If the VM starts checking that to
> decide whether it should call shrinkers, things will continue to work.
> Increment and decrement NR_SLAB_UNRECLAIMABLE when we grow/shrink the
> SLOB pool. This is probably 3 lines of code total.
>
> C) Fake NR_SLAB_RECLAIMABLE/NR_SLAB_UNRECLAIMABLE based on actual
> allocs and slab flags such that they sum to the total pages in the
> SLOB pool. This would need a third global counter in bytes of how many
> allocs we had in the "reclaimable" slabs. Probably 10-20 lines of
> code of marginal utility.
>
> So, nothing insurmountable here. Just not convinced we should bother.
> But the cost of B is so low, perhaps I might as well.
D) Do the right thing and implement the counters.
At the time of calling alloc_pages() you know that you have to increment
either counter but you do not know which.
For that purpose you add another byte counter (reclaim_counter) that
contains the number of reclaimable bytes allocated. Sum them up during
slob_alloc if flags & SLAB_RECLAIM_ACCOUNT is set.
Then after a page allocator alloc you check the following:
If (NR_SLAB_RECLAIMABLE << PAGE_SHIFT) >= reclaim_counter then increment
NR_SLAB_UNRECLAIMABLE otherwise NR_SLAB_RECLAIMABLE.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 16:36 ` Christoph Lameter
@ 2007-05-24 17:22 ` Matt Mackall
2007-05-24 17:27 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Matt Mackall @ 2007-05-24 17:22 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Thu, May 24, 2007 at 09:36:16AM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Matt Mackall wrote:
>
> > So, here's three possible approaches to this issue:
> >
> > A) Continue to ignore it. Doing something about it would add
> > complexity and it's not clear that it's a win.
> >
> > B) Set NR_SLAB_RECLAIMABLE to 1. If the VM starts checking that to
> > decide whether it should call shrinkers, things will continue to work.
> > Increment and decrement NR_SLAB_UNRECLAIMABLE when we grow/shrink the
> > SLOB pool. This is probably 3 lines of code total.
> >
> > C) Fake NR_SLAB_RECLAIMABLE/NR_SLAB_UNRECLAIMABLE based on actual
> > allocs and slab flags such that they sum to the total pages in the
> > SLOB pool. This would need a third global counter in bytes of how many
> > allocs we had in the "reclaimable" slabs. Probably 10-20 lines of
> > code of marginal utility.
> >
> > So, nothing insurmountable here. Just not convinced we should bother.
> > But the cost of B is so low, perhaps I might as well.
>
> D) Do the right thing and implement the counters.
That's C) above. But you haven't answered the real question: why
bother? RECLAIMABLE is a bogus number and the VM treats it as such. We
can make no judgment on how much memory we can actually reclaim from
looking at reclaimable - it might very easily all be pinned.
RECLAIMABLE+UNRECLAIMABLE is a more interesting number - the total
memory used by the allocator. But that's mostly interesting as a
user-level diagnostic.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 17:22 ` Matt Mackall
@ 2007-05-24 17:27 ` Christoph Lameter
2007-05-24 17:44 ` Matt Mackall
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 17:27 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Matt Mackall wrote:
> That's C) above. But you haven't answered the real question: why
> bother? RECLAIMABLE is a bogus number and the VM treats it as such. We
> can make no judgment on how much memory we can actually reclaim from
> looking at reclaimable - it might very easily all be pinned.
The memory was allocated from a slab that has SLAB_ACCOUNT_RECLAIM set. It
is the responsibility of the slab allocator to properly account for these.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 17:27 ` Christoph Lameter
@ 2007-05-24 17:44 ` Matt Mackall
0 siblings, 0 replies; 66+ messages in thread
From: Matt Mackall @ 2007-05-24 17:44 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Thu, May 24, 2007 at 10:27:54AM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Matt Mackall wrote:
>
> > That's C) above. But you haven't answered the real question: why
> > bother? RECLAIMABLE is a bogus number and the VM treats it as such. We
> > can make no judgment on how much memory we can actually reclaim from
> > looking at reclaimable - it might very easily all be pinned.
>
> The memory was allocated from a slab that has SLAB_ACCOUNT_RECLAIM set. It
> is the responsibility of the slab allocator to properly account for these.
You keep asserting this, but the fact is if I ripped out all the
SLAB_ACCOUNT_RECLAIM logic, the kernel would be unaffected.
Because RECLAIM IS JUST A HINT. And not a very good one.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 6:17 ` Nick Piggin
2007-05-23 6:28 ` Christoph Lameter
@ 2007-05-23 6:38 ` Christoph Lameter
2007-05-23 7:18 ` Nick Piggin
2007-05-23 7:46 ` Nick Piggin
2 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 6:38 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> OK, so with a 64-bit UP ppc kernel, compiled for size, and without full
> size data structures, booting with mem=16M init=/bin/bash.
Hmmm.. Cannot do much on such a system. Try a 32 bit instead?
> After booting and mounting /proc, SLOB has 1140K free, SLUB has 748K
> free.
The following patch may help a little bit but not much. Hmmm... In order
to reduce the space further we would also have to shrink all caches when
boot is complete. Elimination of useless caches also would be good.
Do you really want to go into this deeper?
---
include/linux/slub_def.h | 2 ++
mm/slub.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h 2007-05-22 22:46:06.000000000 -0700
+++ slub/include/linux/slub_def.h 2007-05-22 23:31:18.000000000 -0700
@@ -17,7 +17,9 @@ struct kmem_cache_node {
unsigned long nr_partial;
atomic_long_t nr_slabs;
struct list_head partial;
+#ifdef CONFIG_SLUB_DEBUG
struct list_head full;
+#endif
};
/*
Index: slub/mm/slub.c
===================================================================
--- slub.orig/mm/slub.c 2007-05-22 22:46:06.000000000 -0700
+++ slub/mm/slub.c 2007-05-22 23:32:00.000000000 -0700
@@ -183,7 +183,7 @@ static inline void ClearSlabDebug(struct
* Mininum number of partial slabs. These will be left on the partial
* lists even if they are empty. kmem_cache_shrink may reclaim them.
*/
-#define MIN_PARTIAL 2
+#define MIN_PARTIAL 0
/*
* Maximum number of desirable partial slabs.
@@ -1792,7 +1792,9 @@ static void init_kmem_cache_node(struct
atomic_long_set(&n->nr_slabs, 0);
spin_lock_init(&n->list_lock);
INIT_LIST_HEAD(&n->partial);
+#ifdef CONFIG_SLUB_DEBUG
INIT_LIST_HEAD(&n->full);
+#endif
}
#ifdef CONFIG_NUMA
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 6:38 ` Christoph Lameter
@ 2007-05-23 7:18 ` Nick Piggin
2007-05-23 17:06 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 7:18 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Tue, May 22, 2007 at 11:38:54PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > OK, so with a 64-bit UP ppc kernel, compiled for size, and without full
> > size data structures, booting with mem=16M init=/bin/bash.
>
> Hmmm.. Cannot do much on such a system. Try a 32 bit instead?
I could try, at some point.
> > After booting and mounting /proc, SLOB has 1140K free, SLUB has 748K
> > free.
>
> The following patch may help a little bit but not much. Hmmm... In order
> to reduce the space further we would also have to shrink all caches when
> boot is complete. Elimination of useless caches also would be good.
> Do you really want to go into this deeper?
Well you asked the question what good is SLOB when we have SLUB, and the
answer, not surprisingly, still seems to be that it is better for memory
constrained environments.
I'm happy to test any patches from you. If you are able to make SLUB as
space efficient as SLOB on small systems, that would be great, and we
could talk about replacing that too. I think it would be a hefty task,
though.
> ---
> include/linux/slub_def.h | 2 ++
> mm/slub.c | 4 +++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> Index: slub/include/linux/slub_def.h
> ===================================================================
> --- slub.orig/include/linux/slub_def.h 2007-05-22 22:46:06.000000000 -0700
> +++ slub/include/linux/slub_def.h 2007-05-22 23:31:18.000000000 -0700
> @@ -17,7 +17,9 @@ struct kmem_cache_node {
> unsigned long nr_partial;
> atomic_long_t nr_slabs;
> struct list_head partial;
> +#ifdef CONFIG_SLUB_DEBUG
> struct list_head full;
> +#endif
> };
>
> /*
> Index: slub/mm/slub.c
> ===================================================================
> --- slub.orig/mm/slub.c 2007-05-22 22:46:06.000000000 -0700
> +++ slub/mm/slub.c 2007-05-22 23:32:00.000000000 -0700
> @@ -183,7 +183,7 @@ static inline void ClearSlabDebug(struct
> * Mininum number of partial slabs. These will be left on the partial
> * lists even if they are empty. kmem_cache_shrink may reclaim them.
> */
> -#define MIN_PARTIAL 2
> +#define MIN_PARTIAL 0
>
> /*
> * Maximum number of desirable partial slabs.
> @@ -1792,7 +1792,9 @@ static void init_kmem_cache_node(struct
> atomic_long_set(&n->nr_slabs, 0);
> spin_lock_init(&n->list_lock);
> INIT_LIST_HEAD(&n->partial);
> +#ifdef CONFIG_SLUB_DEBUG
> INIT_LIST_HEAD(&n->full);
> +#endif
> }
>
> #ifdef CONFIG_NUMA
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 7:18 ` Nick Piggin
@ 2007-05-23 17:06 ` Christoph Lameter
0 siblings, 0 replies; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 17:06 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> > The following patch may help a little bit but not much. Hmmm... In order
> > to reduce the space further we would also have to shrink all caches when
> > boot is complete. Elimination of useless caches also would be good.
> > Do you really want to go into this deeper?
>
> Well you asked the question what good is SLOB when we have SLUB, and the
> answer, not surprisingly, still seems to be that it is better for memory
> constrained environments.
Well there is not much difference as far as I can see and we have not
focuses on reducing memory wastage by caching.
> I'm happy to test any patches from you. If you are able to make SLUB as
> space efficient as SLOB on small systems, that would be great, and we
> could talk about replacing that too. I think it would be a hefty task,
> though.
We can never get there given that SLOB has always been broken and we do
not want to do the same but I think we can get close. I will sent you
another patch today that will avoid keeping cpu slabs around.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 6:17 ` Nick Piggin
2007-05-23 6:28 ` Christoph Lameter
2007-05-23 6:38 ` Christoph Lameter
@ 2007-05-23 7:46 ` Nick Piggin
2007-05-23 17:07 ` Christoph Lameter
2007-05-23 18:04 ` Christoph Lameter
2 siblings, 2 replies; 66+ messages in thread
From: Nick Piggin @ 2007-05-23 7:46 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 08:17:02AM +0200, Nick Piggin wrote:
> On Tue, May 22, 2007 at 10:28:54PM -0700, Christoph Lameter wrote:
> > On Wed, 23 May 2007, Nick Piggin wrote:
> >
> > > > This is intended for distro kernels so that you will not have to rebuild
> > > > the kernel for slab debugging if slab corruption occurs.
> > >
> > > OIC, neat. Anyway, the code size issue is still there, so I will
> > > test with the fix instead.
> >
> > A code size issue? You mean SLUB is code wise larger than SLOB?
>
>
> That's what the numbers I just posted earlier indicate, yes.
>
> If you want to do a memory consumption shootout with SLOB, you need
> all the help you can get ;)
>
> OK, so with a 64-bit UP ppc kernel, compiled for size, and without full
> size data structures, booting with mem=16M init=/bin/bash.
>
> 2.6.22-rc1-mm1 + your fix + my slob patches.
>
> After booting and mounting /proc, SLOB has 1140K free, SLUB has 748K
> free.
Oh, and just out of interest, SLOB before my patches winds up with
1068K free, so it is good to know the patches were able to save a bit
on this setup.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 7:46 ` Nick Piggin
@ 2007-05-23 17:07 ` Christoph Lameter
2007-05-23 19:35 ` Matt Mackall
2007-05-24 3:24 ` Nick Piggin
2007-05-23 18:04 ` Christoph Lameter
1 sibling, 2 replies; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 17:07 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Nick Piggin wrote:
> Oh, and just out of interest, SLOB before my patches winds up with
> 1068K free, so it is good to know the patches were able to save a bit
> on this setup.
Ahhh.. Its you who did the evil deed. By copying SLUB ideas SLOB became
better than SLUB. Wicked.... Lets see how far down we can get SLUB.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 17:07 ` Christoph Lameter
@ 2007-05-23 19:35 ` Matt Mackall
2007-05-23 19:59 ` Christoph Lameter
2007-05-24 3:24 ` Nick Piggin
1 sibling, 1 reply; 66+ messages in thread
From: Matt Mackall @ 2007-05-23 19:35 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 10:07:33AM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > Oh, and just out of interest, SLOB before my patches winds up with
> > 1068K free, so it is good to know the patches were able to save a bit
> > on this setup.
>
> Ahhh.. Its you who did the evil deed. By copying SLUB ideas SLOB became
> better than SLUB.
Uh, what? SLOB's memory usage was already better.
Quoting Nick:
> After booting and mounting /proc, SLOB has 1140K free, SLUB has 748K
> free.
So that's:
748K SLUB
1068K SLOB (old SLOB saves 320K)
1140K SLOB++ (Nick's improvements save an additional 72K for 392K total)
(It'd be nice to have a SLAB number in there for completeness.)
Nick's patches also make SLOB reasonably performant on larger machines
(and can be a bit faster with a little tweaking). But it'll never be
as fast as SLAB or SLUB - it has to walk lists. Similarly, I think
it's basically impossible for a SLAB-like system that segregates
objects of different sizes onto different pages to compete with a
linked-list allocator on size. Especially now that Nick's reduced the
kmalloc overhead to 2 bytes!
So as long as there are machines where 100K or so makes a difference,
there'll be a use for a SLOB-like allocator.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 19:35 ` Matt Mackall
@ 2007-05-23 19:59 ` Christoph Lameter
2007-05-23 20:51 ` Matt Mackall
2007-05-24 3:39 ` Nick Piggin
0 siblings, 2 replies; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 19:59 UTC (permalink / raw)
To: Matt Mackall; +Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, 23 May 2007, Matt Mackall wrote:
> 748K SLUB
> 1068K SLOB (old SLOB saves 320K)
> 1140K SLOB++ (Nick's improvements save an additional 72K for 392K total)
>
> (It'd be nice to have a SLAB number in there for completeness.)
>
> Nick's patches also make SLOB reasonably performant on larger machines
> (and can be a bit faster with a little tweaking). But it'll never be
> as fast as SLAB or SLUB - it has to walk lists. Similarly, I think
> it's basically impossible for a SLAB-like system that segregates
> objects of different sizes onto different pages to compete with a
> linked-list allocator on size. Especially now that Nick's reduced the
> kmalloc overhead to 2 bytes!
>
> So as long as there are machines where 100K or so makes a difference,
> there'll be a use for a SLOB-like allocator.
Hummm... We have not tested with my patch yet. May save another 200k.
And also the situation that Nick created is a bit artificial. One should
at least have half the memory available for user space I would think. If
there is a small difference after bootup then its not worth to keep SLOB
around. In particular since any real user space stuff will likely cause
fragmentation in SLOB which over the long hawl will be a problem vs.
SLA/UB.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 19:59 ` Christoph Lameter
@ 2007-05-23 20:51 ` Matt Mackall
2007-05-24 3:39 ` Nick Piggin
1 sibling, 0 replies; 66+ messages in thread
From: Matt Mackall @ 2007-05-23 20:51 UTC (permalink / raw)
To: Christoph Lameter
Cc: Nick Piggin, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 12:59:05PM -0700, Christoph Lameter wrote:
> In particular since any real user space stuff will likely cause
> fragmentation in SLOB which over the long hawl will be a problem vs.
> SLA/UB.
Please drop this canard. As we've already pointed out a couple times,
there is no evidence for it and 30 years of evidence against.
--
Mathematics is the supreme nostalgia of our time.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 19:59 ` Christoph Lameter
2007-05-23 20:51 ` Matt Mackall
@ 2007-05-24 3:39 ` Nick Piggin
2007-05-24 3:55 ` Christoph Lameter
1 sibling, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 3:39 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 12:59:05PM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Matt Mackall wrote:
>
> > 748K SLUB
> > 1068K SLOB (old SLOB saves 320K)
> > 1140K SLOB++ (Nick's improvements save an additional 72K for 392K total)
> >
> > (It'd be nice to have a SLAB number in there for completeness.)
> >
> > Nick's patches also make SLOB reasonably performant on larger machines
> > (and can be a bit faster with a little tweaking). But it'll never be
> > as fast as SLAB or SLUB - it has to walk lists. Similarly, I think
> > it's basically impossible for a SLAB-like system that segregates
> > objects of different sizes onto different pages to compete with a
> > linked-list allocator on size. Especially now that Nick's reduced the
> > kmalloc overhead to 2 bytes!
> >
> > So as long as there are machines where 100K or so makes a difference,
> > there'll be a use for a SLOB-like allocator.
>
> Hummm... We have not tested with my patch yet. May save another 200k.
Saved 12K. Shuld it have been more? I only applied the last patch you
sent (plus the initial SLUB_DEBUG fix).
> And also the situation that Nick created is a bit artificial. One should
> at least have half the memory available for user space I would think. If
> there is a small difference after bootup then its not worth to keep SLOB
> around.
Admittedly, I am not involved with any such tiny Linux projects, however
why should half of memory be available to userspace? What about a router
or firewall that basically does all work in kernel?
I think a really stripped down system can boot in 2MB of RAM these days,
so after the kernel actually boots, a few K probably == a few % of
remaining available memory.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 3:39 ` Nick Piggin
@ 2007-05-24 3:55 ` Christoph Lameter
2007-05-24 4:13 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 3:55 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Nick Piggin wrote:
> > Hummm... We have not tested with my patch yet. May save another 200k.
>
> Saved 12K. Shuld it have been more? I only applied the last patch you
> sent (plus the initial SLUB_DEBUG fix).
Yeah. The code size should have shrunk significantly. It seems that the
inlining instead of saving memory as on x86_64 wasted memory and ate up
the winnings through the shrink. Could you try the patch before to see how
much actually is saved by shrinking?
> Admittedly, I am not involved with any such tiny Linux projects, however
> why should half of memory be available to userspace? What about a router
> or firewall that basically does all work in kernel?
It would also work fine with SLUB? Its about 12k code + data on
x86_64. I doubt that this would be too much of an issue.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 3:55 ` Christoph Lameter
@ 2007-05-24 4:13 ` Nick Piggin
2007-05-24 4:23 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 4:13 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 08:55:20PM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Nick Piggin wrote:
>
> > > Hummm... We have not tested with my patch yet. May save another 200k.
> >
> > Saved 12K. Shuld it have been more? I only applied the last patch you
> > sent (plus the initial SLUB_DEBUG fix).
>
> Yeah. The code size should have shrunk significantly. It seems that the
> inlining instead of saving memory as on x86_64 wasted memory and ate up
> the winnings through the shrink. Could you try the patch before to see how
> much actually is saved by shrinking?
After
text data bss dec hex filename
7864 3700 176 11740 2ddc mm/slub.o
Before
text data bss dec hex filename
9136 5932 176 15244 3b8c mm/slub.o
But the biggest issue you can see is not text size, because even if
slub.o was 1 byte, its total dynamic memory usage would still be a
lot higher.
> > Admittedly, I am not involved with any such tiny Linux projects, however
> > why should half of memory be available to userspace? What about a router
> > or firewall that basically does all work in kernel?
>
> It would also work fine with SLUB? Its about 12k code + data on
> x86_64. I doubt that this would be too much of an issue.
Well as I said, I am not the one to ask about whether SLUB could replace
SLOB or not. All else being equal, of course it is a good idea.
But what I think is clear is that SLOB simply uses memory more
efficiently than SLUB (in my test, anyway). I don't know how this can
still be in dispute?
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:13 ` Nick Piggin
@ 2007-05-24 4:23 ` Christoph Lameter
2007-05-24 4:31 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 4:23 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Nick Piggin wrote:
> > It would also work fine with SLUB? Its about 12k code + data on
> > x86_64. I doubt that this would be too much of an issue.
>
> Well as I said, I am not the one to ask about whether SLUB could replace
> SLOB or not. All else being equal, of course it is a good idea.
>
> But what I think is clear is that SLOB simply uses memory more
> efficiently than SLUB (in my test, anyway). I don't know how this can
> still be in dispute?
You have shown that SLUB used more memory than SLOB after bootup on PPC64.
But why is still an open question.
It could be the way that SLOB can exploit the page for multiple object
sizes which creates the advantage. If that is the case then we can do
nothing with SLUB.
But there could still be excessive memory allocs with SLUB that we are not
aware of at this point. For example if the page size > 4k then SLUB will
use higher order allocs by default which will increase wastage.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:23 ` Christoph Lameter
@ 2007-05-24 4:31 ` Nick Piggin
2007-05-24 4:35 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 4:31 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 09:23:22PM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Nick Piggin wrote:
>
> > > It would also work fine with SLUB? Its about 12k code + data on
> > > x86_64. I doubt that this would be too much of an issue.
> >
> > Well as I said, I am not the one to ask about whether SLUB could replace
> > SLOB or not. All else being equal, of course it is a good idea.
> >
> > But what I think is clear is that SLOB simply uses memory more
> > efficiently than SLUB (in my test, anyway). I don't know how this can
> > still be in dispute?
>
> You have shown that SLUB used more memory than SLOB after bootup on PPC64.
> But why is still an open question.
I'll take an educated guess and say that SLUB would have more external
fragmentation which would be especially pronounced in small memory
setups. Also, that SLUB's kmalloc slabs would suffer from a lot more
internal fragmentation too, which could be equally significant if not
more (I think this would become relatively more significant than external
fregmentation as you increased memory size).
If you don't think the test is very interesting, I could try any other
sort of test and with i386 or x86-64 if you like.
> It could be the way that SLOB can exploit the page for multiple object
> sizes which creates the advantage. If that is the case then we can do
> nothing with SLUB.
>
> But there could still be excessive memory allocs with SLUB that we are not
> aware of at this point. For example if the page size > 4k then SLUB will
> use higher order allocs by default which will increase wastage.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:31 ` Nick Piggin
@ 2007-05-24 4:35 ` Christoph Lameter
2007-05-24 4:39 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 4:35 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Nick Piggin wrote:
> I'll take an educated guess and say that SLUB would have more external
> fragmentation which would be especially pronounced in small memory
> setups. Also, that SLUB's kmalloc slabs would suffer from a lot more
> internal fragmentation too, which could be equally significant if not
> more (I think this would become relatively more significant than external
> fregmentation as you increased memory size).
Hmmmm... Could be. The kmalloc array is potentially wasting a lot of
memory. I added more smaller kmalloc array elements to SLUB to avoid that
but maybe that is not enough.
> If you don't think the test is very interesting, I could try any other
> sort of test and with i386 or x86-64 if you like.
Let me try some tests on my own first. Just ran a SLOB baseline, should
have some numbers soon.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:35 ` Christoph Lameter
@ 2007-05-24 4:39 ` Nick Piggin
2007-05-24 4:46 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 4:39 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 09:35:52PM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Nick Piggin wrote:
>
> > I'll take an educated guess and say that SLUB would have more external
> > fragmentation which would be especially pronounced in small memory
> > setups. Also, that SLUB's kmalloc slabs would suffer from a lot more
> > internal fragmentation too, which could be equally significant if not
> > more (I think this would become relatively more significant than external
> > fregmentation as you increased memory size).
>
> Hmmmm... Could be. The kmalloc array is potentially wasting a lot of
> memory. I added more smaller kmalloc array elements to SLUB to avoid that
> but maybe that is not enough.
Don't forget that on small memory systems, this could actually be _worse_
because you might be increasing external fragmentation (ie. if there are
only few kmallocs in each slab).
So it might also be an idea to try reducing them as well.
> > If you don't think the test is very interesting, I could try any other
> > sort of test and with i386 or x86-64 if you like.
>
> Let me try some tests on my own first. Just ran a SLOB baseline, should
> have some numbers soon.
Sure.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:39 ` Nick Piggin
@ 2007-05-24 4:46 ` Christoph Lameter
2007-05-24 4:49 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 4:46 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
Hmmm.. This confirms your findings:
16m x86_64 boot with bin/bash
SLOB:
total used free shared buffers cached
Mem: 11660 9344 2316 0 256 3240
-/+ buffers/cache: 5848 5812
SLUB:
total used free shared buffers cached
Mem: 11652 9684 1968 0 256 3240
-/+ buffers/cache: 6188 5464
Swap: 0 0 0
So a little less than 400k wastage.
No changes to the kmalloc array.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:46 ` Christoph Lameter
@ 2007-05-24 4:49 ` Nick Piggin
2007-05-24 5:07 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 4:49 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 09:46:51PM -0700, Christoph Lameter wrote:
> Hmmm.. This confirms your findings:
>
> 16m x86_64 boot with bin/bash
>
> SLOB:
> total used free shared buffers cached
> Mem: 11660 9344 2316 0 256 3240
> -/+ buffers/cache: 5848 5812
>
>
> SLUB:
> total used free shared buffers cached
> Mem: 11652 9684 1968 0 256 3240
> -/+ buffers/cache: 6188 5464
> Swap: 0 0 0
>
> So a little less than 400k wastage.
It would be interesting to see how a 32-bit system goes as well. I'll
try i386 when I get time.
> No changes to the kmalloc array.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:49 ` Nick Piggin
@ 2007-05-24 5:07 ` Christoph Lameter
0 siblings, 0 replies; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 5:07 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
Booted with full slub in 16M. The additional sysfs support etc distorts
the numbers a bit (300k more data) but it allows to run slabinfo.
Seems that we have high kmalloc array use of 64, 128, 256, 1k, 2k and 4k.
There already is a 92 and 192 sized kmalloc cache. Hmmm..... Looks like
we cannot do much about this. Maybe add some odd sized slabs? A 768 byte
sized?
root@(none):/# mount /proc
root@(none):/# mount /sys
root@(none):/# free
total used free shared buffers cached
Mem: 11636 9976 1660 0 256 3240
-/+ buffers/cache: 6480 5156
Swap: 0 0 0
root@(none):/# slabinfo -S
Name Objects Objsize Space Slabs/Part/Cpu O/S O %Fr %Ef Flg
inode_cache 2471 528 1.4M 354/0/1 7 0 0 89 a
:0000128 7070 128 905.2K 221/1/1 32 0 0 99 *
:0001024 646 1024 663.5K 162/1/1 4 0 0 99 *
:a-0000192 2730 192 536.5K 131/0/1 21 0 0 97 *a
:0002048 82 2048 167.9K 41/0/1 2 0 0 100 *
:0000256 528 256 139.2K 34/0/1 16 0 0 97 *
:0000064 1675 64 110.5K 27/2/1 64 0 7 96 *
:0004096 26 4096 106.4K 26/0/1 1 0 0 100 *
radix_tree_node 148 552 90.1K 22/4/1 7 0 18 90
sighand_cache 20 2072 81.9K 20/0/1 1 0 0 50 A
task_struct 20 1856 53.2K 13/6/1 2 0 46 69
:0000192 231 192 45.0K 11/0/1 21 0 0 98 *
reiser_inode_cache 66 632 45.0K 11/0/1 6 0 0 92 a
kmalloc-8192 5 8192 40.9K 5/0/1 1 1 0 100
:0000512 72 512 36.8K 9/0/1 8 0 0 100 *
idr_layer_cache 30 528 24.5K 6/3/1 7 0 50 64
:0000032 623 32 20.4K 5/2/1 128 0 40 97 *
:0000704 25 696 20.4K 5/0/1 5 0 0 84 *A
:0000016 1280 16 20.4K 5/0/1 256 0 0 100 *
kmalloc-8 2046 8 16.3K 4/1/1 512 0 25 99
buffer_head 111 104 12.2K 3/1/1 39 0 33 93 a
vm_area_struct 48 168 8.1K 2/0/1 24 0 0 98
:0000096 84 96 8.1K 2/0/1 42 0 0 98 *
sock_inode_cache 12 600 8.1K 2/0/1 6 0 0 87 Aa
blkdev_requests 26 280 8.1K 2/1/1 14 0 50 88
blkdev_queue 4 1448 8.1K 2/0/1 2 0 0 70
revokefs_inode_cache 7 552 4.0K 1/0/1 7 0 0 94 Aa
bdev_cache 5 720 4.0K 1/0/1 5 0 0 87 Aa
mm_struct 4 792 4.0K 1/0/1 4 0 0 77 A
sigqueue 25 160 4.0K 1/0/1 25 0 0 97
proc_inode_cache 7 560 4.0K 1/0/1 7 0 0 95 a
Acpi-State 51 80 4.0K 1/0/1 51 0 0 99
mqueue_inode_cache 4 800 4.0K 1/0/1 4 0 0 78 A
anon_vma 170 16 4.0K 1/0/1 170 0 0 66
:0000640 6 616 4.0K 1/0/1 6 0 0 90 *A
shmem_inode_cache 1 712 4.0K 1/1/0 5 0 100 17
root@(none):/# slabinfo -a
:0000016 <- biovec-1 kmalloc-16
:0000024 <- xfs_dabuf xfs_bmap_free_item fasync_cache swapped_entry
:0000032 <- tcp_bind_bucket kmalloc-32 Acpi-Namespace
:0000040 <- inotify_event_cache xfs_chashlist Acpi-Parse dnotify_cache
:0000064 <- blkdev_ioc secpath_cache inet_peer_cache fs_cache
uid_cache xfs_ifork Acpi-ParseExt Acpi-Operand kmalloc-64 pid biovec-4
:0000072 <- eventpoll_pwq inotify_watch_cache
:0000096 <- xfs_ioend kmalloc-96
:0000128 <- kmalloc-128 request_sock_TCP sysfs_dir_cache flow_cache
bio eventpoll_epi
:0000192 <- xfs_ili xfs_btree_cur kmalloc-192 tw_sock_TCP
:0000256 <- filp sgpool-8 mnt_cache kiocb biovec-16 kmalloc-256
arp_cache
:0000320 <- ip_dst_cache kioctx xfs_buf
:0000512 <- kmalloc-512 sgpool-16
:0000640 <- files_cache UNIX
:0000704 <- RAW UDP-Lite UDP signal_cache
:0001024 <- kmalloc-1024 biovec-64 sgpool-32
:0002048 <- kmalloc-2048 sgpool-64 biovec-128
:0004096 <- sgpool-128 biovec-256 kmalloc-4096 names_cache
:a-0000192 <- skbuff_head_cache dentry
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 17:07 ` Christoph Lameter
2007-05-23 19:35 ` Matt Mackall
@ 2007-05-24 3:24 ` Nick Piggin
2007-05-24 3:49 ` Christoph Lameter
1 sibling, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 3:24 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 10:07:33AM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > Oh, and just out of interest, SLOB before my patches winds up with
> > 1068K free, so it is good to know the patches were able to save a bit
> > on this setup.
>
> Ahhh.. Its you who did the evil deed. By copying SLUB ideas SLOB became
> better than SLUB. Wicked.... Lets see how far down we can get SLUB.
Not to be petty, but actually I didn't copy anything from SLUB and still
haven't looked at the code beyond changing the bit spinlock to use a
non-atomic store with my new bitops patches.
The reason SLOB is so space efficient really comes from Matt's no
compromises design. The thrust of my patches were after seeing how slow
it was on my 4GB system while testing the RCU implementation. They
were primarily intended to speed up the thing, but retain all the same
basic allocation algorithms -- a quirk of my implementation allowed
smaller freelist indexes which was a bonus, but as Matt said, slob was
still more efficient before the change.
What SLUB idea did you think I copied anyway?
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 3:24 ` Nick Piggin
@ 2007-05-24 3:49 ` Christoph Lameter
2007-05-24 4:01 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 3:49 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Nick Piggin wrote:
> The reason SLOB is so space efficient really comes from Matt's no
> compromises design. The thrust of my patches were after seeing how slow
> it was on my 4GB system while testing the RCU implementation. They
> were primarily intended to speed up the thing, but retain all the same
> basic allocation algorithms -- a quirk of my implementation allowed
> smaller freelist indexes which was a bonus, but as Matt said, slob was
> still more efficient before the change.
Well as far as I understand Matt it seems that you still need 2 bytes per
alloc. That is still more than 0 that SLUB needs.
> What SLUB idea did you think I copied anyway?
The use of the page struct.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 3:49 ` Christoph Lameter
@ 2007-05-24 4:01 ` Nick Piggin
2007-05-24 4:05 ` Christoph Lameter
0 siblings, 1 reply; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 4:01 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 08:49:30PM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Nick Piggin wrote:
>
> > The reason SLOB is so space efficient really comes from Matt's no
> > compromises design. The thrust of my patches were after seeing how slow
> > it was on my 4GB system while testing the RCU implementation. They
> > were primarily intended to speed up the thing, but retain all the same
> > basic allocation algorithms -- a quirk of my implementation allowed
> > smaller freelist indexes which was a bonus, but as Matt said, slob was
> > still more efficient before the change.
>
> Well as far as I understand Matt it seems that you still need 2 bytes per
> alloc. That is still more than 0 that SLUB needs.
That's true, but I think the more relevant number is that SLUB needs
400K more memory to boot into /bin/bash.
> > What SLUB idea did you think I copied anyway?
>
> The use of the page struct.
The general use of struct page to store page metadata other than pagecache?
I guess not, because that predates SLUB and even SLAB. You've got a
freelist pointer in there, so maybe that's what you mean. I was hoping
for something that I actually can "steal" to make SLOB even better ;)
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:01 ` Nick Piggin
@ 2007-05-24 4:05 ` Christoph Lameter
2007-05-24 4:24 ` Nick Piggin
0 siblings, 1 reply; 66+ messages in thread
From: Christoph Lameter @ 2007-05-24 4:05 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Thu, 24 May 2007, Nick Piggin wrote:
> > Well as far as I understand Matt it seems that you still need 2 bytes per
> > alloc. That is still more than 0 that SLUB needs.
>
> That's true, but I think the more relevant number is that SLUB needs
> 400K more memory to boot into /bin/bash.
I am bit amazed by that. Where is that memory going to? What page size
does the system have?
If we have 4k pages there then this boils down to 100 pages.
Does booting with
slub_max_order=0
change things?
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-24 4:05 ` Christoph Lameter
@ 2007-05-24 4:24 ` Nick Piggin
0 siblings, 0 replies; 66+ messages in thread
From: Nick Piggin @ 2007-05-24 4:24 UTC (permalink / raw)
To: Christoph Lameter
Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
On Wed, May 23, 2007 at 09:05:20PM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Nick Piggin wrote:
>
> > > Well as far as I understand Matt it seems that you still need 2 bytes per
> > > alloc. That is still more than 0 that SLUB needs.
> >
> > That's true, but I think the more relevant number is that SLUB needs
> > 400K more memory to boot into /bin/bash.
>
> I am bit amazed by that. Where is that memory going to?
Well, you tell me, you're the SLUB guy ;)
> What page size
> does the system have?
>
> If we have 4k pages there then this boils down to 100 pages.
Yep, 4K pages.
> Does booting with
>
> slub_max_order=0
>
> change things?
With that, `free` alternates between telling me 764 and 768K free
(without the parameter, it would alternate between 756 and 760). So
yes, marginally.
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [patch 1/3] slob: rework freelist handling
2007-05-23 7:46 ` Nick Piggin
2007-05-23 17:07 ` Christoph Lameter
@ 2007-05-23 18:04 ` Christoph Lameter
1 sibling, 0 replies; 66+ messages in thread
From: Christoph Lameter @ 2007-05-23 18:04 UTC (permalink / raw)
To: Nick Piggin; +Cc: Matt Mackall, Andrew Morton, Linux Memory Management List
Could you try this patch and tell me how much memory it saves?
SLUB embedded: Reduce memory use
If we do not have CONFIG_SLUB_DEBUG set then assume that we need
to conserve memory. So
1. Reduce size of kmem_cache_node
2. Do not keep empty partial slabs around
3. Remove all empty cpu slabs when bootstrap of the kernel
is complete. New cpu slabs will only be added for
the slabs actually used by user space.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
include/linux/slub_def.h | 2 ++
mm/slub.c | 14 ++++++++++++--
2 files changed, 14 insertions(+), 2 deletions(-)
Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h 2007-05-22 22:46:06.000000000 -0700
+++ slub/include/linux/slub_def.h 2007-05-22 23:31:18.000000000 -0700
@@ -17,7 +17,9 @@ struct kmem_cache_node {
unsigned long nr_partial;
atomic_long_t nr_slabs;
struct list_head partial;
+#ifdef CONFIG_SLUB_DEBUG
struct list_head full;
+#endif
};
/*
Index: slub/mm/slub.c
===================================================================
--- slub.orig/mm/slub.c 2007-05-22 22:46:06.000000000 -0700
+++ slub/mm/slub.c 2007-05-23 10:32:36.000000000 -0700
@@ -183,7 +183,11 @@ static inline void ClearSlabDebug(struct
* Mininum number of partial slabs. These will be left on the partial
* lists even if they are empty. kmem_cache_shrink may reclaim them.
*/
+#ifdef CONFIG_SLUB_DEBUG
+#define MIN_PARTIAL 2
+#else
#define MIN_PARTIAL 0
+#endif
/*
* Maximum number of desirable partial slabs.
@@ -1792,7 +1796,9 @@ static void init_kmem_cache_node(struct
atomic_long_set(&n->nr_slabs, 0);
spin_lock_init(&n->list_lock);
INIT_LIST_HEAD(&n->partial);
+#ifdef CONFIG_SLUB_DEBUG
INIT_LIST_HEAD(&n->full);
+#endif
}
#ifdef CONFIG_NUMA
@@ -3659,17 +3665,20 @@ static int sysfs_slab_alias(struct kmem_
return 0;
}
+#endif
static int __init slab_sysfs_init(void)
{
struct list_head *h;
int err;
+#ifdef CONFIG_SLUB_DEBUG
err = subsystem_register(&slab_subsys);
if (err) {
printk(KERN_ERR "Cannot register slab subsystem.\n");
return -ENOSYS;
}
+#endif
slab_state = SYSFS;
list_for_each(h, &slab_caches) {
@@ -3678,8 +3687,10 @@ static int __init slab_sysfs_init(void)
err = sysfs_slab_add(s);
BUG_ON(err);
+ kmem_cache_shrink(s);
}
+#ifdef CONFIG_SLUB_DEBUG
while (alias_list) {
struct saved_alias *al = alias_list;
@@ -3690,8 +3701,7 @@ static int __init slab_sysfs_init(void)
}
resiliency_test();
+#endif
return 0;
}
-
__initcall(slab_sysfs_init);
-#endif
--
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>
^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2007-05-24 17:44 UTC | newest]
Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-22 7:39 [patch 1/3] slob: rework freelist handling Nick Piggin
2007-05-22 7:39 ` [patch 2/3] slob: remove bigblock tracking Nick Piggin
2007-05-22 7:41 ` [patch 3/3] slob: improved alignment handling Nick Piggin
2007-05-22 14:53 ` [patch 1/3] slob: rework freelist handling Matt Mackall
2007-05-22 19:18 ` Christoph Lameter
2007-05-23 3:06 ` Nick Piggin
2007-05-23 4:55 ` Christoph Lameter
2007-05-23 4:59 ` Nick Piggin
2007-05-23 5:01 ` Christoph Lameter
2007-05-23 5:03 ` Nick Piggin
2007-05-23 5:06 ` Christoph Lameter
2007-05-23 5:11 ` Nick Piggin
2007-05-23 5:14 ` Christoph Lameter
2007-05-23 5:22 ` Nick Piggin
2007-05-23 5:28 ` Christoph Lameter
2007-05-23 6:17 ` Nick Piggin
2007-05-23 6:28 ` Christoph Lameter
2007-05-23 7:12 ` Nick Piggin
2007-05-23 17:03 ` Christoph Lameter
2007-05-23 18:32 ` Matt Mackall
2007-05-23 19:15 ` Christoph Lameter
2007-05-23 19:58 ` Matt Mackall
2007-05-23 20:02 ` Christoph Lameter
2007-05-23 20:16 ` Christoph Lameter
2007-05-23 21:14 ` Matt Mackall
2007-05-23 21:06 ` Matt Mackall
2007-05-23 22:26 ` Christoph Lameter
2007-05-23 22:42 ` Matt Mackall
2007-05-23 22:48 ` Christoph Lameter
2007-05-24 2:05 ` Nick Piggin
2007-05-24 2:45 ` Christoph Lameter
2007-05-24 2:47 ` Nick Piggin
2007-05-24 2:55 ` Christoph Lameter
2007-05-24 3:17 ` Nick Piggin
2007-05-24 2:49 ` Christoph Lameter
2007-05-24 3:15 ` Nick Piggin
2007-05-24 3:51 ` Christoph Lameter
2007-05-24 6:11 ` Matt Mackall
2007-05-24 16:36 ` Christoph Lameter
2007-05-24 17:22 ` Matt Mackall
2007-05-24 17:27 ` Christoph Lameter
2007-05-24 17:44 ` Matt Mackall
2007-05-23 6:38 ` Christoph Lameter
2007-05-23 7:18 ` Nick Piggin
2007-05-23 17:06 ` Christoph Lameter
2007-05-23 7:46 ` Nick Piggin
2007-05-23 17:07 ` Christoph Lameter
2007-05-23 19:35 ` Matt Mackall
2007-05-23 19:59 ` Christoph Lameter
2007-05-23 20:51 ` Matt Mackall
2007-05-24 3:39 ` Nick Piggin
2007-05-24 3:55 ` Christoph Lameter
2007-05-24 4:13 ` Nick Piggin
2007-05-24 4:23 ` Christoph Lameter
2007-05-24 4:31 ` Nick Piggin
2007-05-24 4:35 ` Christoph Lameter
2007-05-24 4:39 ` Nick Piggin
2007-05-24 4:46 ` Christoph Lameter
2007-05-24 4:49 ` Nick Piggin
2007-05-24 5:07 ` Christoph Lameter
2007-05-24 3:24 ` Nick Piggin
2007-05-24 3:49 ` Christoph Lameter
2007-05-24 4:01 ` Nick Piggin
2007-05-24 4:05 ` Christoph Lameter
2007-05-24 4:24 ` Nick Piggin
2007-05-23 18:04 ` Christoph Lameter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox