Re: [rfc 04/45] cpu alloc: Use in SLUB

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <clameter@...>
Cc: <ak@...>, <akpm@...>, <travis@...>, <linux-kernel@...>
Date: Tuesday, November 20, 2007 - 8:42 am

* clameter@sgi.com (clameter@sgi.com) wrote:

Normally :

You can't use on_each_cpu if interrupts are already disabled. Therefore,
the implementation using "local_irq_disable/enable" in smp.h for the UP
case is semantically correct and there is no need to use a save/restore.
So just using on_each_cpu should be enough here.

I also wonder about flush_cpu_slab execution on _other_ cpus. I am not
convinced interrupts are disabled when it executes.. have I missing
something ?



I think the preferred coding style is :

c = THIS_CPU(s->cpu_slab);
*pc = c;


I wonder.. are there some architectures that would provide fast
cmpxchg_local but not fast cpu ops ?


Hrm. What happens here if we call __slab_alloc, get a valid object, then
have a CPU_CMPXCHG that fails, restart the loop.. is this case taken
care of or do we end up having an unreferenced object ? Maybe there is
some logic in freelist that takes care of it ?

Also, we have to be aware that we can now change CPU between the

__CPU_READ and the CPU_CMPXCHG. (also : should it be a __CPU_CMPXCHG ?)

But since "object" contains information specific to the local CPU, the
cmpxchg should fail if we are migrated and everything should be ok.

Hrm, actually, the 

c = s->cpu_slab;

should probably be after the object = __CPU_READ(c->freelist); ?

The cpu_read acts as a safeguard checking that we do not change CPU
between the read and the cmpxchg. If we are preempted between the "c"
read and the cpu_read, we could do a !cpu_node_match(c, node) check that
would apply to the wrong cpu.



Same here, c = s->cpu_slab; should probably be read after.


And same question as above : what happens if we fail after executing the
__slab_free.. is it valid to do it twice ?


-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[rfc 04/45] cpu alloc: Use in SLUB, , (Mon Nov 19, 9:11 pm)
Re: [rfc 04/45] cpu alloc: Use in SLUB, Mathieu Desnoyers, (Tue Nov 20, 8:42 am)
Re: [rfc 04/45] cpu alloc: Use in SLUB, Christoph Lameter, (Tue Nov 20, 4:44 pm)
Re: [rfc 04/45] cpu alloc: Use in SLUB, Mathieu Desnoyers, (Tue Nov 20, 5:23 pm)
Re: [rfc 04/45] cpu alloc: Use in SLUB, Christoph Lameter, (Tue Nov 20, 5:36 pm)
Re: [rfc 04/45] cpu alloc: Use in SLUB, Mathieu Desnoyers, (Tue Nov 20, 5:43 pm)