linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Shakeel Butt <shakeelb@google.com>
Cc: Sultan Alsawaf <sultan@kerneltoast.com>,
	Mel Gorman <mgorman@suse.de>, Dave Hansen <dave.hansen@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH] mm: Stop kswapd early when nothing's waiting for it to free pages
Date: Wed, 26 Feb 2020 18:41:04 +0100	[thread overview]
Message-ID: <20200226174104.GO3771@dhcp22.suse.cz> (raw)
In-Reply-To: <CALvZod7BDcHTNY1-yc041nZnKHR2Wo0R-=QXAOYOUEPeyQG4DA@mail.gmail.com>

On Wed 26-02-20 09:00:57, Shakeel Butt wrote:
> On Wed, Feb 26, 2020 at 1:08 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Tue 25-02-20 14:30:03, Shakeel Butt wrote:
> > > On Tue, Feb 25, 2020 at 1:10 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > >
> > > [snip]
> > > >
> > > > The proper fix should, however, check the amount of reclaimable pages
> > > > and back off if they cannot meet the target IMO. We cannot rely on the
> > > > general reclaimability here because that could really be thrashing.
> > > >
> > >
> > > "check the amount of reclaimable pages" vs "cannot rely on the general
> > > reclaimability"? Can you clarify?
> >
> > kswapd targets the high watermark and if your reclaimable memory (aka
> > zone_reclaimable_pages) is lower than the high wmark then it cannot
> > simply satisfy that target, right? Keeping reclaim in that situations
> > seems counter productive to me because you keep evicting pages that
> > might be reused without any feedback mechanism on the actual usage.
> > Please see my other reply.
> >
> 
> I understand and agree with the argument that if reclaimable pages are
> less than high wmark then no need to reclaim. Regarding not depending
> on general reclaimability, I thought you meant that even if
> reclaimable pages are over high wmark, we might not want to continue
> the reclaim to not cause thrashing. Is that right?

That is a completely different story. I would stick with the pathological
problem reported here.  General threshing problem is much more complex
and harder to provide a solution for without introducing a lot of policy
into the reclaim.
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2020-02-26 17:41 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 18:25 Sultan Alsawaf
2020-02-19 19:13 ` Dave Hansen
2020-02-19 19:40   ` Sultan Alsawaf
2020-02-19 20:05     ` Michal Hocko
2020-02-19 20:42       ` Sultan Alsawaf
2020-02-19 21:45         ` Mel Gorman
2020-02-19 22:42           ` Sultan Alsawaf
2020-02-20 10:19             ` Mel Gorman
2020-02-21  4:22               ` Sultan Alsawaf
2020-02-21  8:07                 ` Michal Hocko
     [not found]                   ` <20200221210824.GA3605@sultan-book.localdomain>
2020-02-21 21:24                     ` Dave Hansen
2020-02-25  9:09                     ` Michal Hocko
2020-02-25 17:12                       ` Sultan Alsawaf
2020-02-26  9:05                         ` Michal Hocko
2020-02-25 22:30                       ` Shakeel Butt
2020-02-26  9:08                         ` Michal Hocko
2020-02-26 17:00                           ` Shakeel Butt
2020-02-26 17:41                             ` Michal Hocko [this message]
2020-02-26 10:51                       ` Hillf Danton
2020-02-26 17:04                         ` Shakeel Butt
2020-02-27  1:48                         ` Hillf Danton
2020-02-21 18:04                 ` Shakeel Butt
2020-02-21 20:06                   ` Sultan Alsawaf
2020-02-20  8:29         ` Michal Hocko
2020-02-19 19:26 ` Andrew Morton
2020-02-19 22:45   ` Sultan Alsawaf
2020-02-19 19:35 ` Michal Hocko
2020-02-21  4:30 ` [PATCH v2] " Sultan Alsawaf
2020-02-21 18:22   ` Ira Weiny
2020-02-21 20:00     ` Sultan Alsawaf

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=20200226174104.GO3771@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=shakeelb@google.com \
    --cc=sultan@kerneltoast.com \
    /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