Messages in this thread Patch in this message | | | Date | Mon, 24 May 2004 14:53:03 -0700 | From | Andrew Morton <> | Subject | Re: Slab cache reap and CPU availability |
| |
Dimitri Sivanich <sivanich@sgi.com> wrote: > > > Do you have stack backtraces? I thought the problem was via the RCU > > softirq callbacks, not via the timer interrupt. Dipankar spent some time > > looking at the RCU-related problem but solutions are not comfortable. > > > > What workload is triggering this? > > > > The IA/64 backtrace with all the cruft removed looks as follows: > > 0xa000000100149ac0 reap_timer_fnc+0x100 > 0xa0000001000f4d70 run_timer_softirq+0x2d0 > 0xa0000001000e9440 __do_softirq+0x200 > 0xa0000001000e94e0 do_softirq+0x80 > 0xa000000100017f50 ia64_handle_irq+0x190 > > The system is running mostly AIM7, but I've seen holdoffs > 30 usec with > virtually no load on the system.
They're pretty low latencies you're talking about there.
You should be able to reduce the amount of work in that timer handler by limiting the size of the per-cpu caches in the slab allocator. You can do that by writing a magic incantation to /proc/slabinfo or:
--- 25/mm/slab.c~a Mon May 24 14:51:32 2004 +++ 25-akpm/mm/slab.c Mon May 24 14:51:37 2004 @@ -2642,6 +2642,7 @@ static void enable_cpucache (kmem_cache_ if (limit > 32) limit = 32; #endif + limit = 8; err = do_tune_cpucache(cachep, limit, (limit+1)/2, shared); if (err) printk(KERN_ERR "enable_cpucache failed for %s, error %d.\n", _
> Which uncomfortable solutions (which could relate to this case) have been > investigated?
That work was focussed on the amount of work which is performed in a single RCU callback, not in the slab timer handler. - 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/
| |