Linux kernel: the cost of immediate descheduling

From the http://lkml.indiana.edu/hypermail/linux/kernel/0103.1/0030.html I learn about a new type of mutexes in linux, an adaptive_np one:

The PTHRED_MUTEX_ADAPTIVE_NP is a new mutex that is intended for high throughput at the sacrifice of fairness and even CPU cycles. This mutex does not transfer ownership to a开发者_如何学C waiting thread, but rather allows for competition. Also, over an SMP kernel, the lock operation uses spinning to retry the lock to avoid the cost of immediate descheduling.

There is mentioned "Cost of immediate descheduling". How much is this cost? (In terms of cpu ticks; TLB, TSS, smth else reloading) What is done in kernel between an "immediate descheduling request" and rescheduling back to the run state again?

How can I do a explicit descheduling and how can I measure its cost?

It looks like it's just a lightweight interlock intended to allow threads to avoid the scheduler.

The idea is to replace a relatively heavy context-switch-based operation with a hopefully-short period of time spent in a spinlock.

Disregard the use of "new", spinlocks are as old as the hills. It was, I guess, new to that pthread library almost 10 years ago.

An "explicit descheduling" is presumably the same thing as a context switch, so you could measure this by having two threads yield() the CPU to each other a million times and measure the runtime.