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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
