KOSAKI Motohiro wrote: >> Currently the problem we are hitting is that we cannot specify pdflush >> to have background limits less than 1% of memory. I am currently >> finishing up a patch right now that adds a dirty_ratio_millis >> interface. I hope to submit the patch to LKML by the end of the week. >> >> The idea is that we don't want to break backwards compatibility and we >> also don't want to have two conflicting knobs in the sysctl or >> /proc/sys/vm/ space. I thought adding a new knob for those who want to >> specify finer grained functionality was a compromise. So the patch has >> a vm_dirty_ratio and a vm_dirty_ratio_millis interface. The first to >> specify 0-100% and the second to specify .0 to .999%. >> >> So to represent 0.125% of RAM we set >> vm_dirty_ratio = 0 >> vm_dirty_ratio_millis = 125 >> >> The same for the background_ratio. > > Why vm_dirty_ratio = 0.125 is wrong? > it is hardly for parser maker, but it have nicer user experience. > >> I would also prefer using a bytes interface but I am not sure how to >> offer that without either removing the legacy interface of the ratios >> or by offering a concurrent interface that might be confusing such as >> when users are looking at the old one and not aware of a new one. >> >> Any feedback? > > Sure. > We don't have any motivation of its interface change. The more I think about this and the more I would prefer to have an interface in KB (or pages) that automatically adjusts the old int percentage in dirty_ratio (the same for dirty_background_ratio). The parser issue for writing decimal values doesn't seem to be a big problem, but if the user expects to read an int from vm_dirty_ratio and instead receives something like 0.125, well... this could break something. So, IMHO also in this way we're changing the kernel-userspace interface. -Andrea _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers