Subject: Re: sched_m2 is too unfair
To: None <email@example.com, firstname.lastname@example.org>
From: Mindaugas R. <rmind@NetBSD.org>
Date: 10/29/2007 17:51:37
> >Number: 37245
> >Category: kern
> >Synopsis: sched_m2 is too unfair
> see the following test program and an output of top.
> there seems to be two problems, at least:
> - cpu-hogging threads never moves between cpus unless
> there are idle cpus.
Yes, this case is known. The problem is with CPU-hogging threads, which
never sleeps - they dance only with sched_dequeue/sched_enqueue via
preempt/mi_switch, thus never gets sched_takecpu. There are few more cases:
- STOPPED -> RUN or SUSPENDED -> RUN transitions;
For the first case, I am thinking to perform sched_takecpu() in setrunnable().
> - balance cpus periodically.
I was thinking about calling sched_takecpu() in preempt() when that is
necessary, according to the data collected by sched_balance().
Did you meant something else?
> - there are threads which get completely starved.
> i guess they have never got run after fork and their sl_lrtime
> are still 0.
> - make sched_enqueue initialize l_lrtime properly for new lwps.
I think changing the else case in sched_enqueue to this would be correct:
} else if (sil->sl_lrtime == 0)
sil->sl_lrtime = hardclock_ticks;