On Wed, 5 Nov 2008, Andrew Morton wrote: > See, here's my problem: we have a pile of new code which fixes some > problem. But the problem seems to be fairly small - it only affects a > small number of sophisticated users and they already have workarounds > in place. > The workarounds, while restrictive of how you configure your cpusets, are indeed effective. > So the world wouldn't end if we just didn't merge it. Those users > stick with their workarounds and the kernel remains simpler and > smaller. > Agreed. This patchset is admittedly from a different time when cpusets was the only relevant extension that needed to be done. > How do we work out which is the best choice here? I don't have enough > information to do this. > If we are to support memcg-specific dirty ratios, that requires the aforementioned statistics to be collected so that the calculation is even possible. The series at http://marc.info/?l=linux-kernel&m=122123225006571 http://marc.info/?l=linux-kernel&m=122123241106902 is a step in that direction, although I'd prefer to see NR_UNSTABLE_NFS to be extracted separately from MEM_CGROUP_STAT_FILE_DIRTY so throttle_vm_writeout() can also use the new statistics. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers