Hi, Paul Menage Thank you for your comments > Control Groups is just a framework for associating state with > (user-created) groups of processes. So if you have a problem to solve > that involves tracking state for different processes, or applying > different behaviour to groups of processes based on that group's > state, then cgroups may well be an appropriate tool. > > In the case you mention (management of new devices) that's already > somewhat covered by the existing device isolation subsystem - you can > create a cgroup that has (or doesn't have) access to particular HW > devices. > In some aspect, your opinion is right. Existing controller(ex. disk IO controllers) can be run on new HW devices(ex. SSD), existing block layer and so on. but, what I mean is that such controllers can support more performance if the controllers are rewrited with reconsideration of the features of new HW devices. in other words, what I mean can be optimization of controllers for new devices For example, In case of SSD, current IO scheduler layer is needed ? although i can not sure about it ^^ or process sleep is needed after throwing the IO requests to storage ? the role of page cache in SSD or NVRAM is less important than in normal HDD and .... I heard that many research centers in comanies and universities have studied about smiliar research of course, it can be OS itself, device drivers, block layer, file systems and memory management Under this trend, I just wonder whether the trend can be reflected to cgroup based controllers or not. and whether it is meaningful or not? How do you think about this? My opinion may be some humble ^^ Thank you -- Best Regards, Dong-Jae Kang -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
