Re: [Lse-tech] Re: a quest for a better scheduler

[Hubertus Franke]

Correct, that's true.

Our patch does various things.
(a) limit search for a task to a admin specified set of cpu's
    during schedule()..
(b) limits search for a preemptable task to another set of cpu's
    during reschedule_idle()
     <need to reactivate this functionality 10 lines of code>
(c) loadbalancing, i.e. moving from queue to queue.
    Currently we balance within a set and across sets.

Obviously in NUMA one could specify
     (a) such that multiple sets fall into the same node
         no node crossings.
     (b) specify this set to at least span a node
     (c) do some intelligent moving based on memory maps
          etc.

I guess (c) would be first instance on where to plug architecture
dependent information, e.g. how much memory footprint does a task
have on a particular node and how much would the moving cost.
The loadbalance we provide is a simple sceleton to tickle you mind,
not a solution. Nevertheless, one can see it can have some impact.

See for results for various combinations of poolsizes and balancings:
http://lse.sourceforge.net/scheduling/results012501/status.html#Load%20Balancing

Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)

email: [e-mail]
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003

Kanoj Sarcar <[e-mail]> on 04/04/2001 01:14:28 PM

To:   Hubertus Franke/Watson/IBM@IBMUS
cc:   [e-mail] (Linux Kernel List),
      [e-mail]
Subject:  Re: [Lse-tech] Re: a quest for a better scheduler

>
>
>
> Kanoj, our cpu-pooling + loadbalancing allows you to do that.
> The system adminstrator can specify at runtime through a
> /proc filesystem interface the cpu-pool-size, whether loadbalacing
> should take place.

Yes, I think this approach can support the various requirements
put on the scheduler.

I think there are two degrees of freedom that are needed in the
scheduler. One, as you say, for the sysadmin to be able to specify
what overall scheduler behavior he wants.

Secondly, from the kernel standpoint, there needs to be perarch
hooks, to be able to utilize nodelevel/multilevel caches, NUMA
aspects etc.

Kanoj