I agree with 97% of what you write, Chandra.
> one more level of indirection(instead of task->cpuset->cpus_allowed
> it will be task->taskclass->res[CPUSET]->cpus_allowed).
No -- two more levels of indirection (task->cpus_allowed becomes
task->taskclass->res[CPUSET]->cpus_allowed).
> But, for
On Fri, Feb 11, 2005 at 01:21:12AM -0800, Paul Jackson wrote:
> [ For those who have already reached a conclusion on this
> subject, there is little that is new below. It's just
> cast in a different light, as an analysis of how well
> the CKRM cpuset/memset task class that Chandra describes
On Friday, February 11, 2005 10:42 am, Chandra Seetharaman wrote:
> My email was intented mainly to erase the notion that ckrm cannot handle
> cpuset. Also, I wanted to understand if there is any real issues and that
> is why I talked with Matt about why he thought ckrm cannot accomodate
> memset b
On Fri, Feb 11, 2005 at 08:54:52AM -0800, Jesse Barnes wrote:
> On Thursday, February 10, 2005 6:46 pm, Chandra Seetharaman wrote:
> > On Wed, Feb 09, 2005 at 09:59:28AM -0800, Chandra Seetharaman wrote:
> > > On Tue, Feb 08, 2005 at 12:42:34PM -0800, Paul Jackson wrote:
> >
> > --stuff deleted---
On Thursday, February 10, 2005 6:46 pm, Chandra Seetharaman wrote:
> On Wed, Feb 09, 2005 at 09:59:28AM -0800, Chandra Seetharaman wrote:
> > On Tue, Feb 08, 2005 at 12:42:34PM -0800, Paul Jackson wrote:
>
> --stuff deleted---
>
> > memset_controller would be similar to this, before pitching it I w
[ For those who have already reached a conclusion on this
subject, there is little that is new below. It's just
cast in a different light, as an analysis of how well
the CKRM cpuset/memset task class that Chandra describes
meets the needs of cpusets. The conclusion is: not well.
A pic
On Wed, Feb 09, 2005 at 09:59:28AM -0800, Chandra Seetharaman wrote:
> On Tue, Feb 08, 2005 at 12:42:34PM -0800, Paul Jackson wrote:
--stuff deleted---
> memset_controller would be similar to this, before pitching it I will talk
> with Matt about why he thought that there is a problem.
Talked to M
On Tue, Feb 08, 2005 at 12:42:34PM -0800, Paul Jackson wrote:
> Matthew wrote:
>
> I found no useful and significant basis for integration of cpusets and
> CKRM either involving CPU or Memory Node management.
>
> As best as I can figure out, CKRM is a fair share scheduler with a
> gussied up more
Nick wrote:
> The biggest issues may be the userspace
> interface and a decent userspace management tool.
One possibility, perhaps, would be to have a boolean flag "sched_domain"
on each cpuset, indicating whether it was a sched domain or not. If a
cpuset had its sched_domain flag set, then that
Matthew Dobson wrote:
Nick Piggin wrote:
I didn't really follow where that idea went, but I think at least
a few people thought that sort of functionality wasn't nearly
fancy enough! :)
Well, that's about how far the idea was supposed to go. ;) I think
named hierarchical sched_domains would off
Shailabh wrote:
> Well, I'm not sure I want to minutely examine Paul's choice of words !
You're a wise man ;).
> Rereading the earlier posts on the thread, I'd agree. There are some
> similarities in our interfaces but not enough to warrant a merger.
As I said ... a wise man !
--
Matthew wrote:
> I should have been more clear that CKRM and CPUSETs (seem) to
> be unreconcilable. Sched_domains and CPUSETs (seem) to have some potential
> functionality overlap that leads me to (still) believe there is hope to
> integrate these two systems.
Aha - now we're getting somewhere
As best as I can figure out, CKRM is a fair share scheduler with a
gussied up more modular architecture, so that the components to track
usage, control (throttle) tasks, and classify tasks are separate
plugins.
> I'm not an expert on CKRM, so I'll leave the refuting (or notrefuting)
> of your cl
Martin J. Bligh wrote:
What about your proposed sched domain changes?
Cant sched domains be used handle the CPU groupings and the
existing code in cpusets that handle memory continue as is?
Weren't sched somains supposed to give the scheduler better knowledge
of the CPU groupings afterall ?
sched d
Martin J. Bligh wrote:
Sorry to reply a long quiet thread, but I've been trading emails with
Paul Jackson on this subject recently, and I've been unable to convince
either him or myself that merging CPUSETs and CKRM is as easy as I once
believed. I'm still convinced the CPU side is doable, but
Paul Jackson wrote:
Matthew wrote:
The reason Paul and I decided that they weren't totally reconcilable is
because of the memory binding side of the CPUSETs code.
Speak for yourself, Matthew ;).
I agree you that the scheduler experts (I'm not one, nor do I aspire to
be one) may well find that it
Matthew wrote:
> The reason Paul and I decided that they weren't totally reconcilable is
> because of the memory binding side of the CPUSETs code.
Speak for yourself, Matthew ;).
I agree you that the scheduler experts (I'm not one, nor do I aspire to
be one) may well find that it makes sense s
Nick Piggin wrote:
Dinakar Guniguntala wrote:
On Mon, Feb 07, 2005 at 03:59:49PM -0800, Matthew Dobson wrote:
Sorry to reply a long quiet thread, but I've been trading emails with
Paul Jackson on this subject recently, and I've been unable to
convince either him or myself that merging CPUSETs an
Dinakar Guniguntala wrote:
On Mon, Feb 07, 2005 at 03:59:49PM -0800, Matthew Dobson wrote:
Sorry to reply a long quiet thread, but I've been trading emails with Paul
Jackson on this subject recently, and I've been unable to convince either
him or myself that merging CPUSETs and CKRM is as easy a
> Sorry to reply a long quiet thread, but I've been trading emails with
> Paul Jackson on this subject recently, and I've been unable to convince
> either him or myself that merging CPUSETs and CKRM is as easy as I once
> believed. I'm still convinced the CPU side is doable, but I haven't
> ma
>> What about your proposed sched domain changes?
>> Cant sched domains be used handle the CPU groupings and the
>> existing code in cpusets that handle memory continue as is?
>> Weren't sched somains supposed to give the scheduler better knowledge
>> of the CPU groupings afterall ?
>>
>
> sched
Dinakar Guniguntala wrote:
On Mon, Feb 07, 2005 at 03:59:49PM -0800, Matthew Dobson wrote:
Sorry to reply a long quiet thread, but I've been trading emails with Paul
Jackson on this subject recently, and I've been unable to convince either
him or myself that merging CPUSETs and CKRM is as easy a
On Mon, Feb 07, 2005 at 03:59:49PM -0800, Matthew Dobson wrote:
> Sorry to reply a long quiet thread, but I've been trading emails with Paul
> Jackson on this subject recently, and I've been unable to convince either
> him or myself that merging CPUSETs and CKRM is as easy as I once believed.
Andrew wrote:
> OK, I'll add cpusets to the 2.6.12 queue.
I'd like that ;).
Thank-you, Matthew, for the work you put into making sense of this.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECT
Matthew Dobson <[EMAIL PROTECTED]> wrote:
>
> Sorry to reply a long quiet thread,
Is appreciated, thanks.
> but I've been trading emails with Paul
> Jackson on this subject recently, and I've been unable to convince either him
> or myself that merging CPUSETs and CKRM is as easy as I once belie
Matthew Dobson wrote:
On Sun, 2004-10-03 at 16:53, Martin J. Bligh wrote:
Martin wrote:
Matt had proposed having a separate sched_domain tree for each cpuset, which
made a lot of sense, but seemed harder to do in practice because "exclusive"
in cpusets doesn't really mean exclusive at all.
See my c
26 matches
Mail list logo
