On 12/21/11 17:16, KOSAKI Motohiro wrote: >>> So for 2MB kernel that's about 20KB of an additional text... This seems >>> affordable, especially as a trade-off for the things that cgroups may >>> provide. >> >> A comment from http://lkml.indiana.edu/hypermail/linux/kernel/1102.1/00412.html: >> >> "I care about 5K. (But honestly, I don't actively hunt stuff less than >> 10K in size, because there's too many of them to chase, currently)." > > Hm, interesting. Because of, current memory cgroup notification was > made by a request from Sony and CELinux. AFAIK, at least, Sony > are already using cgroups. Sony makes a very large range of products. The memory available on the different products can range from a few megabytes to hundreds of megabytes (and I wouldn't be surprised if the top of the range is gigabytes). Our low memory products lead us to be concerned about the growth in memory usage by newer kernel versions. Of course we also like additional features and kernel improvements, so we understand the balancing act of features requiring more memory, while at the same time discouraging memory growth for resource constrained systems. Config options are one of the tools used to manage that balancing act. >>> The fact is, for desktop and server Linux, cgroups slowly becomes a >>> mandatory thing. And the reason for this is that cgroups mechanism >>> provides some very useful features (in an extensible way, like plugins), >>> i.e. a way to manage and track processes and its resources -- which is the >>> main purpose of cgroups. >> >> And for embedded and for real-time, some of us do not want cgroups to be >> a mandatory thing. We want it to remain configurable. My personal >> interest is in keeping the latency of certain critical paths (especially >> in the scheduler) short and consistent. > > As far as I observed, modern embedded system have both RT and no RT process. > Java VM or user downloadable programs may need memory notification > because users may download bad programs. in the other hand, rt > processes are not downloadable and much tested by hardware vendor. So, > I think you only need > split process between under cgroups and not under cgroups. > > cgroups have zero or much likely zero overhead if the processes don't use it. > Of course, feedback are welcome. I'm interesting your embedded usecase. No, cgroups have _near_ zero overhead when the cgroup configuration option is turned off. :-) (Sorry, being pedantic, but still serious.) Again, we have many different products. Some may find cgroups to be useful. But at least one of our product groups totally removed the cgroups source code from their scheduler as part of their focus on reducing latency. We have to think about a wide range of (sometimes conflicting) requirements. Config options help us choose which features to enable for each product, resolving some of the conflicting requirements. -Frank -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>