From: Michal Hocko <mhocko@suse.cz>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
minchan@kernel.org, anton@enomsg.org, akpm@linux-foundation.org,
kmpark@infradead.org, hyunhee.kim@samsung.com
Subject: Re: [PATCH v2] vmpressure: implement strict mode
Date: Thu, 27 Jun 2013 16:59:43 +0200 [thread overview]
Message-ID: <20130627145943.GB24206@dhcp22.suse.cz> (raw)
In-Reply-To: <20130627093407.0466ced2@redhat.com>
On Thu 27-06-13 09:34:07, Luiz Capitulino wrote:
> On Thu, 27 Jun 2013 11:26:16 +0200
> Michal Hocko <mhocko@suse.cz> wrote:
> > On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
[...]
> > > +Applications can also choose between two notification modes when
> > > +registering an eventfd for memory pressure events:
> > > +
> > > +When in "non-strict" mode, an eventfd is notified for the specific level
> > > +it's registered for and higher levels. For example, an eventfd registered
> > > +for low level is also going to be notified on medium and critical levels.
> > > +This mode makes sense for applications interested on monitoring reclaim
> > > +activity or implementing simple load-balacing logic. The non-strict mode
> > > +is the default notification mode.
> > > +
> > > +When in "strict" mode, an eventfd is strictly notified for the pressure
> > > +level it's registered for. For example, an eventfd registered for the low
> > > +level event is not going to be notified when memory pressure gets into
> > > +medium or critical levels. This allows for more complex logic based on
> > > +the actual pressure level the system is experiencing.
> >
> > It would be also fair to mention that there is no guarantee that lower
> > levels are signaled before higher so nobody should rely on seeing LOW
> > before MEDIUM or CRITICAL.
>
> I think this is implied. Actually, as an user of this interface I didn't
> expect this to happen until I read the code.
That is a difference between the two modes, so let's better be _explicit_
about that. There is some confusion about that, considering the last
discussions. And I am not that surprised because critical memory
pressure should have passed low and medium levels first is not entirely
unreasonable expectation. But this is _not_ how this interface works or
will guarantee to work in future.
[...]
> > > diff --git a/mm/vmpressure.c b/mm/vmpressure.c
> > > index 736a601..ba5c17e 100644
> > > --- a/mm/vmpressure.c
> > > +++ b/mm/vmpressure.c
> > > @@ -138,8 +138,16 @@ struct vmpressure_event {
> > > struct eventfd_ctx *efd;
> > > enum vmpressure_levels level;
> > > struct list_head node;
> > > + unsigned int mode;
> >
> > You would fill up a hole between level and node if you move it up on
> > 64b. Doesn't matter much but why not do it...
>
> You want me to respin?
I will leave it to you. This is not anything earth shattering as we
won't have zillions of this structures so saving few bytes doesn't help
us that much and 32b doesn't have to hole.
--
Michal Hocko
SUSE Labs
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-06-27 14:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-27 3:17 Luiz Capitulino
2013-06-27 9:26 ` Michal Hocko
2013-06-27 13:34 ` Luiz Capitulino
2013-06-27 14:59 ` Michal Hocko [this message]
2013-06-27 15:53 ` Minchan Kim
2013-06-27 17:42 ` Michal Hocko
2013-06-27 15:44 ` Minchan Kim
2013-06-27 22:02 ` Andrew Morton
2013-06-28 0:02 ` Minchan Kim
2013-06-28 0:34 ` Andrew Morton
2013-06-28 0:58 ` Anton Vorontsov
2013-06-28 1:13 ` Andrew Morton
2013-06-28 4:34 ` Anton Vorontsov
2013-06-28 5:07 ` Anton Vorontsov
2013-06-28 14:00 ` Luiz Capitulino
2013-06-28 16:57 ` Anton Vorontsov
2013-06-28 17:09 ` Anton Vorontsov
2013-06-28 18:25 ` Luiz Capitulino
2013-06-28 18:45 ` Anton Vorontsov
2013-06-28 18:58 ` Luiz Capitulino
2013-06-28 18:45 ` Luiz Capitulino
2013-06-28 18:55 ` Anton Vorontsov
2013-06-28 19:44 ` Luiz Capitulino
2013-06-29 0:56 ` Anton Vorontsov
2013-07-01 8:22 ` Hyunhee Kim
2013-07-02 4:32 ` Anton Vorontsov
2013-07-02 8:29 ` Hyunhee Kim
2013-07-02 13:29 ` Michal Hocko
2013-07-02 14:59 ` Luiz Capitulino
2013-07-02 17:24 ` Anton Vorontsov
2013-07-02 18:38 ` Luiz Capitulino
2013-06-28 5:24 ` Andrew Morton
2013-06-28 13:43 ` Luiz Capitulino
2013-06-28 9:04 ` Minchan Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130627145943.GB24206@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=anton@enomsg.org \
--cc=hyunhee.kim@samsung.com \
--cc=kmpark@infradead.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox