* Christoph Lameter ([EMAIL PROTECTED]) wrote: > On Wed, 22 Aug 2007, Mathieu Desnoyers wrote: > > > * Christoph Lameter ([EMAIL PROTECTED]) wrote: > > > void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags) > > > @@ -1577,7 +1590,10 @@ static void __slab_free(struct kmem_cach > > > { > > > void *prior; > > > void **object = (void *)x; > > > + unsigned long flags; > > > > > > + local_irq_save(flags); > > > + put_cpu_no_resched(); > > > > Those two lines may skip a preempt_check. > > Yes we cannot execute something else here. > > > Could we change them to this instead ? > > > > put_cpu(); > > local_irq_save(flags); > > Then the thread could be preempted and rescheduled on a different cpu > between put_cpu and local_irq_save() which means that we loose the > state information of the kmem_cache_cpu structure. >
Maybe am I misunderstanding something, but kmem_cache_cpu does not seem to be passed to __slab_free() at all, nor any data referenced by it. So why do we care about being preempted there ? > > Otherwise, it would be good to call > > > > preempt_check_resched(); > > > > After each local_irq_restore() in this function. > > We could do that but maybe the frequency of these checks would be too > high? When should the resched checks be used? Since we are only doing this on the slow path, it does not hurt. preempt_check_resched() is embedded in preempt_enable() and has a very low impact (simple thread flag check in the standard case). Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/