lkml.org 
[lkml]   [2005]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: 2.6.13-rc3-mm1 (ckrm)
From
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
> 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 driver, this would not be a big problem.
> That's not the case.

I believe this feature would also make desktop users happier -- controlling
X-server, mpeg player, video capturing and all that -- if the code
becomes much simpler and easier to use.

> A major restructuring of this patch set could be considered, This
> might involve making the metric tools (that monitor memory, fork
> and network usage rates per task) separate patches useful for other
> purposes. It might also make the rate limiters in fork, alloc and
> network i/o separately useful patches. I mean here genuinely useful
> and understandable in their own right, independent of some abstract
> CKRM framework.

That makes sense.

> Though hints have been dropped, I have not seen any public effort to
> integrate CKRM with either cpusets or scheduler domains or process
> accounting. By this I don't mean recoding cpusets using the CKRM
> infrastructure; that proposal received _extensive_ consideration
> earlier, and I am as certain as ever that it made no sense. Rather I
> could imagine the CKRM folks extending cpusets to manage resources
> on a per-cpuset basis, not just on a per-task or task class basis.
> Similarly, it might make sense to use CKRM to manage resources on
> a per-sched domain basis, and to integrate the resource tracking
> of CKRM with the resource tracking needs of system accounting.

From a standpoint of the users, CKRM and CPUSETS should be managed
seamlessly through the same interface though I'm not sure whether
your idea is the best yet.


Thanks,
Hirokazu Takahashi.
-
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-07-18 12:17    [from the cache]
©2003-2011 Jasper Spaans