Re: [PATCH]: Clean up of __alloc_pages

[Nick Piggin <nickpiggin@yahoo.com.au>]

Paul Jackson wrote:
> Nick wrote:

>>>And is the pair of operators:
>>>  task_lock(current), task_unlock(current)
>>>really that much worse than the pair of operators
>>>  ...
>>>  preempt_disable, preempt_enable
> 
> 
> That part still surprises me a little.  Is there enough difference in
> the performance between:
> 
>   1) task_lock, which is a spinlock on current->alloc_lock and
>   2) rcu_read_lock, which is .preempt_count++; barrier()
> 
> to justify a separate slab cache for cpusets and a little more code?
> 
> For all I know (not much) the task_lock might actually be cheaper ;).
> 

But on a preempt kernel the spinlock must disable preempt as well!

Not to mention that a spinlock is an atomic op (though that is getting
cheaper these days) + 2 memory barriers (getting more expensive).

> The semaphore down means doing an atomic_dec_return(), which imposes
> a memory barrier, right?
> 

Yep.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com