Re: [PATCH]: Clean up of __alloc_pages

Nick Piggin
2005-11-07T10:15:27Z

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