Seems like subj could provide a very flexible approach for managing memory in complicated scenarios. Depending on memory limits it could work as mlock (with lock-on-fault semantics). Binding files to cgroup with small memory limit gives long-awaited FADV_NOREUSE semantics. Even without limits this gives valuable information about memory usage by page-cache for particular set of files. For example, our database keeps data in several files with completely different access patterns: some of them should be cached and locked in memory (but not completely), some shouldn't be cached because cache-hit is almost impossible and so on. fadvise and mlock provides some tuning but they are very limited. Interface could be done as a single fadvise(fd, FADV_WILLOWN) which binds inode to current memory cgroup (fails if already binded) and migrates all present cache. All further allocations in this inode will be charged to that cgroup. In userspace this will be used by tiny tool which lives in target cgroup and holds all binded files, so state will be persistent but without keeping anything in fs. So, what do you think? Is there any plans to alter always-charge-to-current logic? -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
