From: Minchan Kim <minchan@kernel.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>, Vlastimil Babka <vbabka@suse.cz>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned
Date: Thu, 28 Jul 2016 10:38:22 +0900 [thread overview]
Message-ID: <20160728013822.GC6974@bbox> (raw)
In-Reply-To: <20160725092014.GL10438@techsingularity.net>
On Mon, Jul 25, 2016 at 10:20:14AM +0100, Mel Gorman wrote:
> On Mon, Jul 25, 2016 at 05:04:56PM +0900, Minchan Kim wrote:
> > > @@ -1429,6 +1429,9 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
> > > continue;
> > > }
> > >
> > > + /* Pages skipped do not contribute to scan */
> > > + scan++;
> > > +
> >
> > As I mentioned in previous version, under irq-disabled-spin-lock, such
> > unbounded operation would make the latency spike worse if there are
> > lot of pages we should skip.
> >
> > Don't we take care it?
>
> It's not unbounded, it's bound by the size of the LRU list and it's not
> going to be enough to trigger a warning. While the lock hold time may be
> undesirable, unlocking it every SWAP_CLUSTER_MAX pages may increase overall
> contention. There also is the question of whether skipped pages should be
> temporarily putback before unlocking the LRU to avoid isolated pages being
> unavailable for too long. It also cannot easily just return early without
> prematurely triggering OOM due to a lack of progress. I didn't feel the
> complexity was justified.
I measured the lock holding time and it took max 96ms during 360M
scanning with hackbench. It was very easy to reproduce with node-lru
because it should skip too many pages.
Given that my box is much faster than usual mobile CPU, it would
take more time in embedded system. I think irq disable during 96ms would
be worth to be fixed.
Anyway, I'm done by that which I measured time by hand so it's up to you
that whether you want to fix or leave as it is until someone reports it with
more real workload.
>
> --
> Mel Gorman
> 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>
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>, Vlastimil Babka <vbabka@suse.cz>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned
Date: Thu, 28 Jul 2016 10:38:22 +0900 [thread overview]
Message-ID: <20160728013822.GC6974@bbox> (raw)
In-Reply-To: <20160725092014.GL10438@techsingularity.net>
On Mon, Jul 25, 2016 at 10:20:14AM +0100, Mel Gorman wrote:
> On Mon, Jul 25, 2016 at 05:04:56PM +0900, Minchan Kim wrote:
> > > @@ -1429,6 +1429,9 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
> > > continue;
> > > }
> > >
> > > + /* Pages skipped do not contribute to scan */
> > > + scan++;
> > > +
> >
> > As I mentioned in previous version, under irq-disabled-spin-lock, such
> > unbounded operation would make the latency spike worse if there are
> > lot of pages we should skip.
> >
> > Don't we take care it?
>
> It's not unbounded, it's bound by the size of the LRU list and it's not
> going to be enough to trigger a warning. While the lock hold time may be
> undesirable, unlocking it every SWAP_CLUSTER_MAX pages may increase overall
> contention. There also is the question of whether skipped pages should be
> temporarily putback before unlocking the LRU to avoid isolated pages being
> unavailable for too long. It also cannot easily just return early without
> prematurely triggering OOM due to a lack of progress. I didn't feel the
> complexity was justified.
I measured the lock holding time and it took max 96ms during 360M
scanning with hackbench. It was very easy to reproduce with node-lru
because it should skip too many pages.
Given that my box is much faster than usual mobile CPU, it would
take more time in embedded system. I think irq disable during 96ms would
be worth to be fixed.
Anyway, I'm done by that which I measured time by hand so it's up to you
that whether you want to fix or leave as it is until someone reports it with
more real workload.
>
> --
> Mel Gorman
> 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:[~2016-07-28 1:37 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-20 15:21 [PATCH 0/5] Candidate fixes for premature OOM kills with node-lru v1 Mel Gorman
2016-07-20 15:21 ` Mel Gorman
2016-07-20 15:21 ` [PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned Mel Gorman
2016-07-20 15:21 ` Mel Gorman
2016-07-21 5:16 ` Minchan Kim
2016-07-21 5:16 ` Minchan Kim
2016-07-21 8:15 ` Mel Gorman
2016-07-21 8:15 ` Mel Gorman
2016-07-21 8:31 ` Minchan Kim
2016-07-21 8:31 ` Minchan Kim
2016-07-25 8:04 ` Minchan Kim
2016-07-25 8:04 ` Minchan Kim
2016-07-25 9:20 ` Mel Gorman
2016-07-25 9:20 ` Mel Gorman
2016-07-28 1:38 ` Minchan Kim [this message]
2016-07-28 1:38 ` Minchan Kim
2016-07-20 15:21 ` [PATCH 2/5] mm: add per-zone lru list stat Mel Gorman
2016-07-20 15:21 ` Mel Gorman
2016-07-21 7:10 ` Joonsoo Kim
2016-07-21 7:10 ` Joonsoo Kim
2016-07-23 0:45 ` Fengguang Wu
2016-07-23 0:45 ` Fengguang Wu
2016-07-23 1:25 ` Minchan Kim
2016-07-23 1:25 ` Minchan Kim
2016-07-20 15:21 ` [PATCH 3/5] mm, vmscan: Remove highmem_file_pages Mel Gorman
2016-07-20 15:21 ` Mel Gorman
2016-07-20 15:21 ` [PATCH 4/5] mm: Remove reclaim and compaction retry approximations Mel Gorman
2016-07-20 15:21 ` Mel Gorman
2016-07-20 15:21 ` [PATCH 5/5] mm: consider per-zone inactive ratio to deactivate Mel Gorman
2016-07-20 15:21 ` Mel Gorman
2016-07-21 5:30 ` Minchan Kim
2016-07-21 5:30 ` Minchan Kim
2016-07-21 8:08 ` Mel Gorman
2016-07-21 8:08 ` Mel Gorman
2016-07-21 7:10 ` Joonsoo Kim
2016-07-21 7:10 ` Joonsoo Kim
2016-07-21 8:16 ` Mel Gorman
2016-07-21 8:16 ` Mel Gorman
2016-07-21 7:07 ` [PATCH 0/5] Candidate fixes for premature OOM kills with node-lru v1 Minchan Kim
2016-07-21 7:07 ` Minchan Kim
2016-07-21 9:15 ` Mel Gorman
2016-07-21 9:15 ` Mel Gorman
2016-07-21 7:31 ` Joonsoo Kim
2016-07-21 7:31 ` Joonsoo Kim
2016-07-21 8:39 ` Minchan Kim
2016-07-21 8:39 ` Minchan Kim
2016-07-21 9:16 ` Mel Gorman
2016-07-21 9:16 ` Mel Gorman
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=20160728013822.GC6974@bbox \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.cz \
--cc=vbabka@suse.cz \
/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.