All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: vinayak menon <vinayakm.list@gmail.com>
Cc: Vinayak Menon <vinmenon@codeaurora.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	mgorman@techsingularity.net, vbabka@suse.cz,
	Rik van Riel <riel@redhat.com>,
	vdavydov.dev@gmail.com, anton.vorontsov@linaro.org,
	Minchan Kim <minchan@kernel.org>,
	shashim@codeaurora.org, "linux-mm@kvack.org" <linux-mm@kvack.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure
Date: Tue, 7 Feb 2017 15:52:57 +0100	[thread overview]
Message-ID: <20170207145257.GT5065@dhcp22.suse.cz> (raw)
In-Reply-To: <CAOaiJ-=B7d9uAkXPdA-F2NFtY4p43xQPG4Pozv3NY9BahFaO3A@mail.gmail.com>

On Tue 07-02-17 18:46:55, vinayak menon wrote:
> On Tue, Feb 7, 2017 at 5:47 PM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Tue 07-02-17 16:39:15, vinayak menon wrote:
[...]
> >> Starting to kill at the right time helps in recovering memory at a
> >> faster rate than waiting for the reclaim to complete. Yes, we may
> >> be able to modify lowmemorykiller to cope with this problem. But
> >> the actual problem this patch tried to fix was the vmpressure event
> >> regression.
> >
> > I am not happy about the regression but you should try to understand
> > that we might end up with another report a month later for a different
> > consumer of events.
>
> I understand that. But this was the way vmpressure had worked until the
> regression and IMHO adding reclaimed slab just increases the noise in
> vmpressure.

I would argue the previous behavior was wrong as well.

> > I believe that the vmpressure needs some serious rethought and come with
> > a more realistic and stable metric.
>
> Okay. I agree. So you are suggesting to drop the patch ?

Unless there is a strong reason to keep it. Your test case seems to be
rather artificial and the behavior is not much better after your patch.
So rather than tunning the broken behavior for a particular test case
I would welcome rethinking the whole thing.

That being said I am not nacking the patch so if others think that this
is a reasonable thing to do for now I will not stand in the way.
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: vinayak menon <vinayakm.list@gmail.com>
Cc: Vinayak Menon <vinmenon@codeaurora.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	mgorman@techsingularity.net, vbabka@suse.cz,
	Rik van Riel <riel@redhat.com>,
	vdavydov.dev@gmail.com, anton.vorontsov@linaro.org,
	Minchan Kim <minchan@kernel.org>,
	shashim@codeaurora.org, "linux-mm@kvack.org" <linux-mm@kvack.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure
Date: Tue, 7 Feb 2017 15:52:57 +0100	[thread overview]
Message-ID: <20170207145257.GT5065@dhcp22.suse.cz> (raw)
In-Reply-To: <CAOaiJ-=B7d9uAkXPdA-F2NFtY4p43xQPG4Pozv3NY9BahFaO3A@mail.gmail.com>

On Tue 07-02-17 18:46:55, vinayak menon wrote:
> On Tue, Feb 7, 2017 at 5:47 PM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Tue 07-02-17 16:39:15, vinayak menon wrote:
[...]
> >> Starting to kill at the right time helps in recovering memory at a
> >> faster rate than waiting for the reclaim to complete. Yes, we may
> >> be able to modify lowmemorykiller to cope with this problem. But
> >> the actual problem this patch tried to fix was the vmpressure event
> >> regression.
> >
> > I am not happy about the regression but you should try to understand
> > that we might end up with another report a month later for a different
> > consumer of events.
>
> I understand that. But this was the way vmpressure had worked until the
> regression and IMHO adding reclaimed slab just increases the noise in
> vmpressure.

I would argue the previous behavior was wrong as well.

> > I believe that the vmpressure needs some serious rethought and come with
> > a more realistic and stable metric.
>
> Okay. I agree. So you are suggesting to drop the patch ?

Unless there is a strong reason to keep it. Your test case seems to be
rather artificial and the behavior is not much better after your patch.
So rather than tunning the broken behavior for a particular test case
I would welcome rethinking the whole thing.

That being said I am not nacking the patch so if others think that this
is a reasonable thing to do for now I will not stand in the way.
-- 
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>

  reply	other threads:[~2017-02-07 14:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06 12:24 [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure Vinayak Menon
2017-02-06 12:24 ` Vinayak Menon
2017-02-06 12:24 ` [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow Vinayak Menon
2017-02-06 12:24   ` Vinayak Menon
2017-02-06 12:40   ` Michal Hocko
2017-02-06 12:40     ` Michal Hocko
2017-02-06 13:09     ` vinayak menon
2017-02-06 13:09       ` vinayak menon
2017-02-06 13:24       ` Michal Hocko
2017-02-06 13:24         ` Michal Hocko
2017-02-06 14:35         ` vinayak menon
2017-02-06 14:35           ` vinayak menon
2017-02-06 15:12           ` Michal Hocko
2017-02-06 15:12             ` Michal Hocko
2017-02-07 11:17             ` vinayak menon
2017-02-07 11:17               ` vinayak menon
2017-02-07 12:09               ` Michal Hocko
2017-02-07 12:09                 ` Michal Hocko
2017-02-06 12:52 ` [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure Michal Hocko
2017-02-06 12:52   ` Michal Hocko
2017-02-06 15:10   ` vinayak menon
2017-02-06 15:10     ` vinayak menon
2017-02-07  8:10     ` Michal Hocko
2017-02-07  8:10       ` Michal Hocko
2017-02-07 11:09       ` vinayak menon
2017-02-07 11:09         ` vinayak menon
2017-02-07 12:17         ` Michal Hocko
2017-02-07 12:17           ` Michal Hocko
2017-02-07 13:16           ` vinayak menon
2017-02-07 13:16             ` vinayak menon
2017-02-07 14:52             ` Michal Hocko [this message]
2017-02-07 14:52               ` 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=20170207145257.GT5065@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anton.vorontsov@linaro.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=shashim@codeaurora.org \
    --cc=vbabka@suse.cz \
    --cc=vdavydov.dev@gmail.com \
    --cc=vinayakm.list@gmail.com \
    --cc=vinmenon@codeaurora.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 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.