linux-kernel - Re: [PATCH -mm v9 0/8] idle memory tracking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150729163725.GZ8100@esperanza>
Date:	Wed, 29 Jul 2015 19:37:26 +0300
From:	Vladimir Davydov <vdavydov@...allels.com>
To:	Andres Lagar-Cavilla <andreslc@...gle.com>
CC:	Michal Hocko <mhocko@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan@...nel.org>,
	"Raghavendra K T" <raghavendra.kt@...ux.vnet.ibm.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Greg Thelen <gthelen@...gle.com>,
	Michel Lespinasse <walken@...gle.com>,
	David Rientjes <rientjes@...gle.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Jonathan Corbet <corbet@....net>, <linux-api@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <linux-mm@...ck.org>,
	<cgroups@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -mm v9 0/8] idle memory tracking

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@...allels.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/