Thanks for your well worded response, Shailabh.
Others will have to make further comments and
decisions here. You have understood what I had
to say, and responded well. I have nothing to
add at this point that would help further.
--
I won't rest till it's the best ...
Paul Jackson wrote:
Sorry for the late response - I just saw this note.
Shailabh wrote:
So if the current CPU controller
implementation is considered too intrusive/unacceptable, it can be
reworked or (and we certainly hope not) even rejected in perpetuity.
It is certainly reasonable t
> > if CKRM is just extensions, I think it should be an external patch.
> > if it provides a path towards unifying the many disparate RM mechanisms
> > already in the kernel, great!
>
> OK, so if it provides a path towards unifying these, what should happen
> to the old interfaces when they confli
On Fri, 2005-07-22 at 20:23 -0400, Mark Hahn wrote:
> > > actually, let me also say that CKRM is on a continuum that includes
> > > current (global) /proc tuning for various subsystems, ulimits, and
> > > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up
> > > being useful an
> > actually, let me also say that CKRM is on a continuum that includes
> > current (global) /proc tuning for various subsystems, ulimits, and
> > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up
> > being useful and fast enough to subsume the current global and per-proc
> >
On Fri, 2005-07-22 at 12:35 -0400, Mark Hahn wrote:
> actually, let me also say that CKRM is on a continuum that includes
> current (global) /proc tuning for various subsystems, ulimits, and
> at the other end, Xen/VMM's. it's conceivable that CKRM could wind up
> being useful and fast enough
Shailabh wrote:
> So if the current CPU controller
> implementation is considered too intrusive/unacceptable, it can be
> reworked or (and we certainly hope not) even rejected in perpetuity.
It is certainly reasonable that you would hope such.
But this hypothetical possibility concerns me a
On Gwe, 2005-07-22 at 12:35 -0400, Mark Hahn wrote:
> I imagine you, like me, are currently sitting in the Xen talk,
Out by a few thousand miles ;)
> and I don't believe they are or will do anything so dumb as to throw away
> or lose information. yes, in principle, the logic will need to be
Th
> > > the fast path slower and less maintainable. if you are really concerned
> > > about isolating many competing servers on a single piece of hardware, then
> > > run separate virtualized environments, each with its own user-space.
> >
> > And the virtualisation layer has to do the same job wit
On Fri, 22 Jul 2005 15:53:55 BST, Alan Cox wrote:
> On Gwe, 2005-07-22 at 00:53 -0400, Mark Hahn wrote:
> > the fast path slower and less maintainable. if you are really concerned
> > about isolating many competing servers on a single piece of hardware, then
> > run separate virtualized environme
On Gwe, 2005-07-22 at 00:53 -0400, Mark Hahn wrote:
> the fast path slower and less maintainable. if you are really concerned
> about isolating many competing servers on a single piece of hardware, then
> run separate virtualized environments, each with its own user-space.
And the virtualisation
> of the various environments. I don't think you are one of those end
> users, though. I don't think I'm required to make everyone happy all
> the time. ;)
the issue is whether CKRM (in it's real form, not this thin edge)
will noticably hurt Linux's fast-path.
-
To unsubscribe from this list:
On Fri, 22 Jul 2005 00:53:58 EDT, Mark Hahn wrote:
> > > > yes, that's the crux. CKRM is all about resolving conflicting resource
> > > > demands in a multi-user, multi-server, multi-purpose machine. this is
> > > > a
> > > > huge undertaking, and I'd argue that it's completely inappropriate
> > > yes, that's the crux. CKRM is all about resolving conflicting resource
> > > demands in a multi-user, multi-server, multi-purpose machine. this is a
> > > huge undertaking, and I'd argue that it's completely inappropriate for
> > > *most* servers. that is, computers are generally so dam
Sorry - I didn't see Mark's original comment, so I'm replying to
a reply which I did get. ;-)
On Thu, 21 Jul 2005 23:59:09 EDT, Shailabh Nagar wrote:
> Mark Hahn wrote:
> >>I suspect that the main problem is that this patch is not a mainstream
> >>kernel feature that will gain multiple uses, but
Paul Jackson wrote:
Martin wrote:
No offense, but I really don't see why this matters at all ... the stuff
in -mm is what's under consideration for merging - what's in SuSE is ...
Yes - what's in SuSE doesn't matter, at least not directly.
No - we are not just considering the CKRM that is i
Mark Hahn wrote:
I suspect that the main problem is that this patch is not a mainstream
kernel feature that will gain multiple uses, but rather provides
support for a specific vendor middleware product used by that
vendor and a few closely allied vendors. If it were smaller or
less intrusive, su
On Fri, 22 Jul 2005 13:46:37 +1000, Peter Williams wrote:
> Gerrit Huizenga wrote:
> >>I imagine that the cpu controller is missing from this version of CKRM
> >>because the bugs introduced to the cpu controller during upgrading from
> >>2.6.5 to 2.6.10 version have not yet been resolved.
> >
>
Martin wrote:
> No offense, but I really don't see why this matters at all ... the stuff
> in -mm is what's under consideration for merging - what's in SuSE is ...
Yes - what's in SuSE doesn't matter, at least not directly.
No - we are not just considering the CKRM that is in *-mm now, but also
w
Gerrit Huizenga wrote:
On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote:
Paul Jackson wrote:
Matthew wrote:
I don't see the large ifdefs you're referring to in -mm's
kernel/sched.c.
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releas
On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote:
> Paul Jackson wrote:
> > Matthew wrote:
> >
> >>I don't see the large ifdefs you're referring to in -mm's
> >>kernel/sched.c.
> >
> >
> > Perhaps someone who knows CKRM better than I can explain why the CKRM
> > version in some SuSE rel
Paul Jackson wrote:
Matthew wrote:
I don't see the large ifdefs you're referring to in -mm's
kernel/sched.c.
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releases based on 2.6.5 kernels has substantial
code and some large ifdef's in sched.c, but
Paul Jackson wrote:
Matthew wrote:
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releases based on 2.6.5 kernels has substantial
code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't.
Or perhaps I'm confused. There's a good chance
Matthew wrote:
> I don't see the large ifdefs you're referring to in -mm's
> kernel/sched.c.
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releases based on 2.6.5 kernels has substantial
code and some large ifdef's in sched.c, but the CKRM in *-mm doesn
On Sun, 2005-07-17 at 08:20 -0700, Paul Jackson wrote:
> It is somewhat intrusive in the areas it controls, such as some large
> ifdef's in kernel/sched.c.
I don't see the large ifdefs you're referring to in -mm's
kernel/sched.c.
> The sched hooks may well impact the cost of maintaining the sch
Well said, Mark. Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
Hi,
> > What, in your opinion, makes it "obviously unmergeable"?
Controlling resource assignment, I think that concept is good.
But the design is another matter that it seems somewhat overkilled
with the current CKRM.
> I suspect that the main problem is that this patch is not a mainstream
> ker
> I suspect that the main problem is that this patch is not a mainstream
> kernel feature that will gain multiple uses, but rather provides
> support for a specific vendor middleware product used by that
> vendor and a few closely allied vendors. If it were smaller or
> less intrusive, such as a d
Andrew, replying to Christoph, about CKRM:
> What, in your opinion, makes it "obviously unmergeable"?
Thanks to some earlier discussions on the relation of CKRM with
cpusets, I've spent some time looking at CKRM. I'm not Christoph,
but perhaps my notes will be of some use in this matter.
CKRM is
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> >
> > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> > ker
30 matches
Mail list logo
