Re: [PATCH]: Clean up of __alloc_pages

[Nick Piggin]

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 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/