From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx175.postini.com [74.125.245.175]) by kanga.kvack.org (Postfix) with SMTP id 584A76B0031 for ; Mon, 10 Jun 2013 21:01:28 -0400 (EDT) Received: by mail-oa0-f43.google.com with SMTP id i7so5326906oag.30 for ; Mon, 10 Jun 2013 18:01:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20130611001747.GA16971@teo> References: <021701ce65cb$a3b9c3b0$eb2d4b10$%kim@samsung.com> <20130610151258.GA14295@dhcp22.suse.cz> <20130611001747.GA16971@teo> Date: Tue, 11 Jun 2013 10:01:27 +0900 Message-ID: Subject: Re: [PATCH] memcg: event control at vmpressure. From: Kyungmin Park Content-Type: multipart/alternative; boundary=089e0149c800d520d704ded66fe5 Sender: owner-linux-mm@kvack.org List-ID: To: Anton Vorontsov Cc: Michal Hocko , Hyunhee Kim , linux-mm@kvack.org --089e0149c800d520d704ded66fe5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 11, 2013 at 9:17 AM, Anton Vorontsov wrote: > On Mon, Jun 10, 2013 at 05:12:58PM +0200, Michal Hocko wrote: > > > + if (level >= ev->level && level != vmpr->current_level) { > > > eventfd_signal(ev->efd, 1); > > > signalled = true; > > > + vmpr->current_level = level; > > > > This would mean that you send a signal for, say, VMPRESSURE_LOW, then > > the reclaim finishes and two days later when you hit the reclaim again > > you would simply miss the event, right? > > > > So, unless I am missing something, then this is plain wrong. > > Yup, in it current version, it is not acceptable. For example, sometimes > we do want to see all the _LOW events, since _LOW level shows not just the > level itself, but the activity (i.e. reclaiming process). > > There are a few ways to make both parties happy, though. > > If the app wants to implement the time-based throttling, then just close > the fd and sleep for needed amount of time (or do not read from the > eventfd -- kernel then will just increment the eventfd counter, so there > won't be context switches at the least). Doing the time-based throttling > in the kernel won't buy us much, I believe. > > Or, if you still want the "one-shot"/"edge-triggered" events (which might > make perfect sense for medium and critical levels), then I'd propose to > add some additional flag when you register the event, so that the old > behaviour would be still available for those who need it. This approach I > think is the best one. > > Ok we will prepare this way and resend it. Thank you, Kyungmin Park --089e0149c800d520d704ded66fe5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 11, 2013 at 9:17 AM, Anton V= orontsov <anton@enomsg.org> wrote:
On Mon, Jun 10, 2013 at 05:12:58PM +0200, Michal Hocko wr= ote:
> > + =A0 =A0 =A0 =A0 =A0 if (level >=3D ev->level && l= evel !=3D vmpr->current_level) {
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 eventfd_signal(ev->efd= , 1);
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 signalled =3D true;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vmpr->current_level =3D = level;
>
> This would mean that you send a signal for, say, VMPRESSURE_LOW, then<= br> > the reclaim finishes and two days later when you hit the reclaim again=
> you would simply miss the event, right?
>
> So, unless I am missing something, then this is plain wrong.

Yup, in it current version, it is not acceptable. For example, someti= mes
we do want to see all the _LOW events, since _LOW level shows not just the<= br> level itself, but the activity (i.e. reclaiming process).

There are a few ways to make both parties happy, though.

If the app wants to implement the time-based throttling, then just close the fd and sleep for needed amount of time (or do not read from the
eventfd -- kernel then will just increment the eventfd counter, so there won't be context switches at the least). Doing the time-based throttlin= g
in the kernel won't buy us much, I believe.

Or, if you still want the "one-shot"/"edge-triggered" e= vents (which might
make perfect sense for medium and critical levels), then I'd propose to=
add some additional flag when you register the event, so that the old
behaviour would be still available for those who need it. This approach I think is the best one.

Ok we will prepare this way and=A0resend it.
=A0
Thank you,
Kyungmin Park=A0
--089e0149c800d520d704ded66fe5-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org