Messages in this thread | | | Date | Fri, 18 Jun 2004 13:40:45 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH]: Option to run cache reap in thread mode |
| |
Dimitri Sivanich <sivanich@sgi.com> wrote: > > At the time of the holdoff (the point where we've spent a total of 30 usec in > the timer_interrupt), we've looped through more than 100 of the 131 caches, > usually closer to 120.
ahh, ooh, ow, of course.
Manfred, we need a separate list of "slabs which might need reaping".
That'll help the average case. To help the worst case we should change cache_reap() to only reap (say) ten caches from the head of the new list and to then return. Maybe increase the timer frequency too.
something like:
/* * FIFO list of caches (via kmem_cache_t.reap_list) which need consideration in * cache_reap(). Protected by cache_chain_sem. */ static LIST_HEAD(global_reap_list);
cache_reap() { for (i = 0; i < 10; i++) { if (list_empty(&global_reap_list)) break; cachep = list_entry(&global_reap_list, kmem_cache_t, reap_list); list_del_init(&cachep->reap_list); <prune it> } }
mark_cache_for_reaping(kmem_cach_t *cachep) { if (list_empty(&cachep->reap_list)) { if (!down_trylock(&cache_chain_sem)) { list_add(&cachep->reap_list, &global_reap_list); up(&cache_chain_sem); } }
Maybe cache_chain_sem should become a spinlock. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |