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
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel
