On Thu, Feb 16, 2012 at 10:43:00AM -0800, Arun Sharma wrote: > On 2/16/12 2:39 AM, Andrea Righi wrote: > > >Arun, thank you very much for your review and testing. Probably we'll > >move to a different, memcg-based solution, so I don't think I'll post > >another version of this patch set as is. In case, I'll apply one of > >the workarounds for the rb_root attribute. > > I'm not sure if the proposed memory.file.limit_in_bytes is the right > interface. Two problems: > > * The user is now required to figure out what is the right amount of > page cache for the app (may change over time) Right. > > * If the app touches two sets of files, one with streaming access > and the other which benefits from page cache (eg: a mapper task in a > map reduce), memcg doesn't allow the user to specify the access > pattern per-fd. Yes, of course the memcg approach is probably too coarse-grained for certain apps. If we want to provide the per-fd granularity the fadvise() solution is a way better. However, the memcg solution could be enough to resolve most of the common data streaming issues (like "the backup is trashing the page cache" problem) and it doesn't require modification of the application source code. This is an important advantage that we shouldn't ignore IMHO, because it means that the new feature will be available _immediately_ for any application. Maybe we should try to push ...something... in the memcg code for the short-term future, make it as much generic as possible, and for the long-term try to reuse the same feature (totally or in part) in the per-fd approach via fadvise(). Thanks, -Andrea -- 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>