Re: RFC for small change to 4bsd scheduler..

From: Bruce Evans <bde_at_zeta.org.au>
Date: Tue, 11 May 2004 00:31:49 +1000 (EST)
On Sun, 9 May 2004, Julian Elischer wrote:

> in the following code:
> struct kse *
> sched_choose(void)
> {
>         struct kse *ke;
>         struct runq *rq;
>
> #ifdef SMP
>         struct kse *kecpu;
>
>         rq = &runq;
>         ke = runq_choose(&runq);
>         kecpu = runq_choose(&runq_pcpu[PCPU_GET(cpuid)]);
>
>         if (ke == NULL ||
>             (kecpu != NULL &&
> **>>>>      kecpu->ke_thread->td_priority <
>                 ke->ke_thread->td_priority)) {
>                      CTR2(KTR_4BSD, "choosing kse %p from pcpu runq %d", kecpu,
>                      PCPU_GET(cpuid));
>                 ke = kecpu;
>                 rq = &runq_pcpu[PCPU_GET(cpuid)];
>         } else {
>                 CTR1(KTR_4BSD, "choosing kse %p from main runq", ke);
>         }
>
>
>
> I think it would be better to have "<=" instead of "<"
>
> I think the current code will make processes of equal priority thrash
> processors if one is on the pcpu list and teh other is on the general
> queue. as it is the pcpu process will only ever run when there is
> nothing of teh same priority to run..

This seems reasonable.  Whether it is really better (or if the pcpu
runq's do anything at all) can probably be tested easily.  Maybe it
matters more for more CPUs.  I haven't seen any benchmark results for
this.

You might also want to compare priorities after dividing by RQ_PPQ (4)
so that certain small differences in priorities have no effect, just
like they would for a single runq.

> maybe there should be code to give such a case a 50/50 chance or
> something?

Priority growth and decay should handle this OK, at least for non-short-
lived processes.  You wouldn't want a 50/50 chance on every call or
anything close to that since it would be thrashing.

Bruce
Received on Mon May 10 2004 - 05:31:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:53 UTC