Messages in this thread | | | Date | Thu, 14 Aug 2008 10:15:56 +0300 | From | Pekka Enberg <> | Subject | Re: No, really, stop trying to delete slab until you've finished making slub perform as well |
| |
Hi Christoph,
Christoph Lameter wrote: > The obvious fix is to avoid allocating another slab on conflict but how will > this impact performance? > > > Index: linux-2.6/mm/slub.c > =================================================================== > --- linux-2.6.orig/mm/slub.c 2008-08-13 08:06:00.000000000 -0500 > +++ linux-2.6/mm/slub.c 2008-08-13 08:07:59.000000000 -0500 > @@ -1253,13 +1253,11 @@ > static inline int lock_and_freeze_slab(struct kmem_cache_node *n, > struct page *page) > { > - if (slab_trylock(page)) { > - list_del(&page->lru); > - n->nr_partial--; > - __SetPageSlubFrozen(page); > - return 1; > - } > - return 0; > + slab_lock(page); > + list_del(&page->lru); > + n->nr_partial--; > + __SetPageSlubFrozen(page); > + return 1; > }
This patch hard locks on my 2-way 64-bit x86 machine (sysrq doesn't respond) when I run hackbench.
| |