Re: [RFC PATCH] Dynamic sched domains (v0.5)

[Dinakar Guniguntala]

On Mon, May 02, 2005 at 11:01:35AM -0700, Paul Jackson wrote:
> My current concerns include:
>  o Having it work on ia64 would facilitate my testing.

   I am working on making changes to ia64, should be ready pretty soon

>  o Does this patch ensure that isolated sched domains form
>       a partition (disjoint cover) of a systems CPUs?  Should it?

   With this patch the cpus of an exclusive cpuset form a sched domain.
   Since only exclusive cpusets can form a sched domain, this ensures
   that the cpus form a disjoint cover

>  o Does this change any documented semantics of cpusets?  I don't
>       see offhand that it does.  Perhaps that's good.  Perhaps
>       I missed something.

   No, all semantics continue to be the same as before


I have trimmed the requirements to do only the absolute minimal in
kernel space

1.  Partitioning of the system (both cpus and memory) to ensure
    dedicated resources are available for application use.
    This has to be done through user space with the help of the
    existing cpuset infrastructure and no additional changes are
    required to be done in the kernel

2.  Remove unnecessary scheduler load balancing overhead in the
    partitions mentioned above
    a. Ensure that load balance code is aware of partitioning of cpus
       and load balance happens within these partitions and not
       across the entire system
    b. Provide for complete removal of load-balancing on a given
       partition of cpus

    This is necessary for a variety of workloads, including real-time,
    HPC and any mix of these workloads
    In the current patch, only 2(a) has been addressed.
    I intend to add support for 2(b) once the current patch is acceptable
    to everyone. I think this should not be a major change

3.  Support CPU hotplug is another requirement, though not a direct one


Hope this helps

	-Dinakar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/