RE: sys_sched_yield fast path

[Davide Libenzi <davidel@xmailserver.org>]

On 10-Mar-2001 Mike Kravetz wrote:
> Any thoughts about adding a 'fast path' to the SMP code in
> sys_sched_yield.  Why not compare nr_pending to smp_num_cpus
> before examining the aligned_data structures?  Something like,
> 
> if (nr_pending > smp_num_cpus)
>       goto set_resched_now;
> 
> Where set_resched_now is a label placed just before the code
> that sets the need_resched field of the current process.
> This would eliminate touching all the aligned_data cache lines
> in the case where nr_pending can never be decremented to zero.
> 
> Also, would it make sense to stop decrementing nr_pending to
> prevent it from going negative?  OR  Is the reasoning that in
> these cases there is so much 'scheduling' activity that we
> should force the reschedule?

Probably the rate at which is called sys_sched_yield() is not so high to let
the performance improvement to be measurable.
If You're going to measure the schedule() speed with the test program in which
the schedule() rate is the same of the sched_yield() rate, this could clean Your
measure of the schedule() speed.




- Davide