lkml.org 
[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement
Date
From
    It's not so much whether they NEED their own scheduler, etc. as whether 
it should be possible for them to have their own scheduler, etc. With a
configurable scheduler (such as ZAPHOD) this could just be a matter of
having separate configuration variables for each cpuset (e.g. if a
cpuset has been created to contain as bunch of servers there's no need
to try and provide good interactive response for its tasks (as none of
them will be interactive) so the interactive response mechanism can be
turned off in that cpuset leading to better server response and throughput).

Providing configurable schedulers is a feature/bug/argument completely
separate from cpusets. Let's stay focused on that for now.

Two concrete examples for cpusets stick in my mind:

* the department that has been given 16 cpus of a 128 cpu machine,
is free to do what they want with them, and doesn't much care
specifically how they're laid out. Think general timeshare.

* the department that has been given 16 cpus of a 128 cpu machine
to run a finely tuned application which expects and needs everybody
to stay off those cpus. Think compute-intensive.

Correct me if I'm wrong, but CKRM can handle the first, but cannot
currently handle the second. And the mechanism(s) for creating either
situation are suboptimal at best and non-existent at worst.

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

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.378 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site