All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyunhee Kim <hyunhee.kim@samsung.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Anton Vorontsov <anton@enomsg.org>,
	linux-mm@kvack.org, akpm@linux-foundation.org, rob@landley.net,
	kamezawa.hiroyu@jp.fujitsu.com, hannes@cmpxchg.org,
	rientjes@google.com, kirill@shutemov.name,
	Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: [PATCH v3] memcg: event control at vmpressure.
Date: Wed, 19 Jun 2013 20:25:03 +0900	[thread overview]
Message-ID: <CAOK=xRPM90muz5nFh8oUVAPFU=e4cwyWPZELVKoXke2FUN9Xsg@mail.gmail.com> (raw)
In-Reply-To: <20130618110151.GI13677@dhcp22.suse.cz>

2013/6/18 Michal Hocko <mhocko@suse.cz>:
> On Tue 18-06-13 17:00:06, Hyunhee Kim wrote:
>> 2013/6/18 Hyunhee Kim <hyunhee.kim@samsung.com>:
>> > 2013/6/17 Michal Hocko <mhocko@suse.cz>:
>> >> On Mon 17-06-13 20:30:11, Hyunhee Kim wrote:
>> >> [...]
>> >>> diff --git a/mm/vmpressure.c b/mm/vmpressure.c
>> >>> index 736a601..a18fdb3 100644
>> >>> --- a/mm/vmpressure.c
>> >>> +++ b/mm/vmpressure.c
>> >> [...]
>> >>> @@ -150,14 +151,16 @@ static bool vmpressure_event(struct vmpressure *vmpr,
>> >>>       level = vmpressure_calc_level(scanned, reclaimed);
>> >>>
>> >>>       mutex_lock(&vmpr->events_lock);
>> >>> -
>> >>>       list_for_each_entry(ev, &vmpr->events, node) {
>> >>>               if (level >= ev->level) {
>> >>> +                     if (ev->edge_trigger && (level == vmpr->last_level
>> >>
>> >>> +                             || level != ev->level))
>> >>
>> >> Hmm, why this differs from the "always" semantic? You do not want to see
>> >> lower events? Why?
>> >
>> > Yes, I didn't want to see every lower level events whenever the higher
>> > level event occurs because the higher event signal implies that the
>> > lower memory situation also occurs.
>
> Is there any guarantee that such a condition would be also signalled?

I think so. In the original implementation, ev is signaled if (level
>= ev->level).
This means that on "level == CRITICAL", LOW and MEDIUM are always
signaled if these are registered and somebody listen to them.
What I wanted to do can be seperated two parts: (1) don't send signals
if the current level is same as the last level. (2) only send the
current level not every lower level.
But, I think that (1) is more close to "edge trigger" and I'll
implement "edge trigger".

>
>> > For example, if CRITICAL event
>> > occurs, it means that LOW and MEDIUM also occur. So, I think that
>> > triggering these lower level events are redundant. And, some users
>> > don't want to see this every event. But, I think that if I don't want
>> > to see lower events, I should add another option.
>
> I think the interface should be consistent with `always' unless there is
> very good reason to do otherwise.
>
>> > Currently, as you mentioned, for edge_trigger option, I'll remove
>> > "level != ev->level" part.
>> >
>> >>
>> >>> +                             continue;
>> >>>                       eventfd_signal(ev->efd, 1);
>> >>>                       signalled = true;
>> >>>               }
>> >>>       }
>> >>> -
>> >>> +     vmpr->last_level = level;
>> >>>       mutex_unlock(&vmpr->events_lock);
>> >>
>> >> I have already asked in the previous version but there was no answer for
>> >> it. So let's try again.
>> >>
>> >> What is the expected semantic when an event is triggered but there is
>> >> nobody to consume it?
>> >> I am not sure that the current implementation is practical. Say that
>> >> last_level is LOW and you just registered your event. Should you see the
>> >> first event or not?
>> >>
>> >> I think that last_level should be per-vmpressure_event and the edge
>> >> would be defined as the even seen for the first time since registration.
>> >
>> > Right. The current implementation could not cover those situations. As
>> > you mentioned, I think that this could be solved by having last_level
>> > per vmpressure_event (after removing "level != ev->level"). If
>> > last_level of each event is set to valid level only after the first
>> > event is signaled, we cannot miss the first signal even when an event
>> > is registered in the middle of runtime.
>> >
>>
>> How about initializing vmpr->last_level = -1 everytime new event is
>> registered? (having last_level per vmpr).
>
> So all those consumers that have seen an event already would be
> surprised that they get the very same event again without transition to
> other level (so it won't be edge triggered anymore). No this doesn't
> make any sense to me.

Right. As you mentioned, if edge trigger option is enabled but same
events are triggered,
it does not mean edge triggered any more. I'll modify it to keep
last_level per vmpressure event.

>
> Please try to think about the interface, what it is supposed to do and
> how it is supposed to behave. The current implementation seems hackish
> to me and it is an example of a single-use-case-designed interface which
> tend to be hard to maintain and a bad idea in long term.
>
>> I think that if we have last_level for each event, only new event
>> could be triggered when the current level is same as the last
>> level. And I think that this is a little awkward.
>
> Why? I might be wrong here but when I register an event I would like to
> get a notification when the event is triggered for the first time from
> my POV. I have no way to find out that such an event has been already
> triggered for somebody else.

Okay, I think that I should keep the meaning of "edge trigger".

>
>> But, if we set vmpr->last_level = -1 when new event is registered,
>> we can see all events with new event even though the level is not
>> changed.
>
> Which basically ruins the idea of the edge triggered event.

Agreed.

Thanks for the comments.
I'll update the patch soon.

Hyunhee Kim.

>
> [...]
> --
> 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>

--
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>

  reply	other threads:[~2013-06-19 11:25 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-17 11:30 [PATCH v3] memcg: event control at vmpressure Hyunhee Kim
2013-06-17 13:15 ` Michal Hocko
2013-06-18  6:10   ` Hyunhee Kim
2013-06-18  8:00     ` Hyunhee Kim
2013-06-18 11:01       ` Michal Hocko
2013-06-19 11:25         ` Hyunhee Kim [this message]
2013-06-19 11:59           ` Michal Hocko
2013-06-19 11:31         ` [PATCH v4] " Hyunhee Kim
2013-06-19 12:53           ` Michal Hocko
2013-06-20  2:13             ` Hyunhee Kim
2013-06-20  2:17             ` [PATCH v5] " Hyunhee Kim
2013-06-20 12:16               ` Michal Hocko
2013-06-21  0:21                 ` [PATCH v6] " Hyunhee Kim
2013-06-21  0:24                   ` Hyunhee Kim
2013-06-21  1:22                     ` Minchan Kim
2013-06-21  9:19                       ` Michal Hocko
2013-06-21 11:02                         ` Hyunhee Kim
2013-06-21 11:54                           ` Hyunhee Kim
2013-06-21 12:40                             ` [PATCH v7] " Hyunhee Kim
2013-06-21 16:27                         ` [PATCH v6] " Minchan Kim
2013-06-21 16:44                           ` Minchan Kim
2013-06-22  0:27                             ` Anton Vorontsov
2013-06-22  1:28                               ` Hyunhee Kim
2013-06-26  7:47                               ` Minchan Kim
2013-06-21 22:35                           ` Anton Vorontsov
2013-06-22  4:36                           ` Hyunhee Kim
2013-06-22  4:51                             ` Hyunhee Kim
2013-06-22  5:50                               ` [PATCH] memcg: consider "scanned < reclaimed" case when calculating Hyunhee Kim
2013-06-22  7:34                                 ` [PATCH] memcg: add interface to specify thresholds of vmpressure Hyunhee Kim
2013-06-25 20:46                                   ` Michal Hocko
2013-06-26  7:39                                   ` Minchan Kim
2013-06-26  7:50                                     ` Kyungmin Park
2013-06-26  8:03                                       ` Minchan Kim
2013-06-26  7:35                                 ` [PATCH] memcg: consider "scanned < reclaimed" case when calculating Minchan Kim
2013-06-27  6:12                                   ` [PATCH v2] vmpressure: consider "scanned < reclaimed" case when calculating a pressure level Hyunhee Kim
2013-06-27  9:37                                     ` Michal Hocko
2013-06-27 15:35                                       ` Minchan Kim
2013-06-27 16:11                                         ` Michal Hocko
2013-06-27 18:05                                           ` Anton Vorontsov
2013-06-28 12:17                                             ` Michal Hocko
2013-06-27 23:54                                           ` Minchan Kim
2013-06-28  7:43                                             ` [PATCH v3] " Hyunhee Kim
2013-06-28 12:26                                               ` Michal Hocko
2013-06-28 12:24                                             ` [PATCH v2] " Michal Hocko
2013-06-28 13:55                                               ` Minchan Kim
2013-06-28 15:17                                                 ` Michal Hocko
2013-06-27 18:33                                     ` Anton Vorontsov
2013-06-26  7:34                               ` [PATCH v6] memcg: event control at vmpressure Minchan Kim
2013-06-26  7:31                             ` Minchan Kim
2013-06-25 16:07                           ` Michal Hocko

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='CAOK=xRPM90muz5nFh8oUVAPFU=e4cwyWPZELVKoXke2FUN9Xsg@mail.gmail.com' \
    --to=hyunhee.kim@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=anton@enomsg.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kirill@shutemov.name \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=rientjes@google.com \
    --cc=rob@landley.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.