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    [W:0.026 / U:31.480 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site