On Wed, Jul 29, 2015 at 08:55:01AM -0700, Andres Lagar-Cavilla wrote: > On Wed, Jul 29, 2015 at 8:28 AM, Vladimir Davydov > <vdavydov@xxxxxxxxxxxxx> wrote: > > On Wed, Jul 29, 2015 at 04:26:19PM +0200, Michal Hocko wrote: > >> On Wed 29-07-15 16:59:07, Vladimir Davydov wrote: > >> > On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote: > >> > > On Sun 19-07-15 15:31:09, Vladimir Davydov wrote: > >> > > [...] > >> > > > ---- USER API ---- > >> > > > > >> > > > The user API consists of two new proc files: > >> > > > >> > > I was thinking about this for a while. I dislike the interface. It is > >> > > quite awkward to use - e.g. you have to read the full memory to check a > >> > > single memcg idleness. This might turn out being a problem especially on > >> > > large machines. > >> > > >> > Yes, with this API estimating the wss of a single memory cgroup will > >> > cost almost as much as doing this for the whole system. > >> > > >> > Come to think of it, does anyone really need to estimate idleness of one > >> > particular cgroup? > > You can always adorn memcg with a boolean, trivially configurable from > user-space, and have all the idle computation paths skip the code if > memcg->dont_care_about_idle Or we can filter out cgroups in which we're not interested using /proc/kpagecgroup. > > >> > >> It is certainly interesting for setting the low limit. > > > > Valuable, IMHO > > > Yes, but IMO there is no point in setting the low limit for one > > particular cgroup w/o considering what's going on with the rest of the > > system. > > > > Probably worth more fleshing out. Why not? Because global reclaim can > execute in any given context, so a noisy neighbor hurts all? The low limit does not necessarily mean, the cgroup will never get pushed below it. It will, if others feel really bad. Also, by setting the low limit too high, you can make others thrash constantly, which will increase IO, which, in turn, might hurt the workload you're trying to protect. Blkio cgroup might help in this case though. Thanks, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
