On 11/25/2014 03:12 AM, Srikar Dronamraju wrote:
- Request to borrow timeslice is not guranteed to be honored.
- If the task is allowed to borrow, kernel will inform the task
of this. When this happens, task must yield the processor as soon
as it completes its critical section.
- If the task fails to yield processor after being allowed to
borrow, it is penalized by forcing it to skip its next time slot
by the scheduler.
- Task is charged additional time for the borrowed timeslice as
accumulated run time. This pushes it further down in consideration
for the next task to run.
Is there a way for us to identify if the lock is contended?
Because it may not be prudent to allow a task to borrow timeslice for a
lock which isnt contended.
Userspace knows that. It is hard to determine this from kernel. Darren
Hart had worked on a solution to solving similar issue and I spent fair
amount of time looking through that code. Darren's solution comes into
play after contention has already happened and does reduce the cost of
contention. Database folks think the cost is already too high once
contention has happened because of the resulting context switches and
post-contention solutions do not help. This solution helps reduce
contention on locks and userspace code designer is in best position to
determine which locks are subject to such contention.
--
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
