Patchwork [2/2] mm: vmscan: If kswapd has been running too long, allow it to sleep

login
register
mail settings
Submitter Mel Gorman
Date May 16, 2011, 3:06 p.m.
Message ID <1305558417-24354-3-git-send-email-mgorman@suse.de>
Download mbox | patch
Permalink /patch/95772/
State Not Applicable
Headers show

Comments

Mel Gorman - May 16, 2011, 3:06 p.m.
Under constant allocation pressure, kswapd can be in the situation where
sleeping_prematurely() will always return true even if kswapd has been
running a long time. Check if kswapd needs to be scheduled.

Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: Rik van Riel <riel@redhat.com>
---
 mm/vmscan.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)
Johannes Weiner - May 16, 2011, 3:26 p.m.
On Mon, May 16, 2011 at 04:06:57PM +0100, Mel Gorman wrote:
> Under constant allocation pressure, kswapd can be in the situation where
> sleeping_prematurely() will always return true even if kswapd has been
> running a long time. Check if kswapd needs to be scheduled.
> 
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Acked-by: Rik van Riel <riel@redhat.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andrew Morton - May 16, 2011, 9:16 p.m.
On Mon, 16 May 2011 16:06:57 +0100
Mel Gorman <mgorman@suse.de> wrote:

> Under constant allocation pressure, kswapd can be in the situation where
> sleeping_prematurely() will always return true even if kswapd has been
> running a long time. Check if kswapd needs to be scheduled.
> 
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Acked-by: Rik van Riel <riel@redhat.com>
> ---
>  mm/vmscan.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index af24d1e..4d24828 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,
>  	unsigned long balanced = 0;
>  	bool all_zones_ok = true;
>  
> +	/* If kswapd has been running too long, just sleep */
> +	if (need_resched())
> +		return false;
> +
>  	/* If a direct reclaimer woke kswapd within HZ/10, it's premature */
>  	if (remaining)
>  		return true;

I'm a bit worried by this one.

Do we really fully understand why kswapd is continuously running like
this?  The changelog makes me think "no" ;)

Given that the page-allocating process is madly reclaiming pages in
direct reclaim (yes?) and that kswapd is madly reclaiming pages on a
different CPU, we should pretty promptly get into a situation where
kswapd can suspend itself.  But that obviously isn't happening.  So
what *is* going on?

Secondly, taking an up-to-100ms sleep in response to a need_resched()
seems pretty savage and I suspect it risks undesirable side-effects.  A
plain old cond_resched() would be more cautious.  But presumably
kswapd() is already running cond_resched() pretty frequently, so why
didn't that work?

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
James Bottomley - May 17, 2011, 6:37 a.m.
On Mon, 2011-05-16 at 14:16 -0700, Andrew Morton wrote:
> On Mon, 16 May 2011 16:06:57 +0100
> Mel Gorman <mgorman@suse.de> wrote:
> 
> > Under constant allocation pressure, kswapd can be in the situation where
> > sleeping_prematurely() will always return true even if kswapd has been
> > running a long time. Check if kswapd needs to be scheduled.
> > 
> > Signed-off-by: Mel Gorman <mgorman@suse.de>
> > Acked-by: Rik van Riel <riel@redhat.com>
> > ---
> >  mm/vmscan.c |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index af24d1e..4d24828 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,
> >  	unsigned long balanced = 0;
> >  	bool all_zones_ok = true;
> >  
> > +	/* If kswapd has been running too long, just sleep */
> > +	if (need_resched())
> > +		return false;
> > +
> >  	/* If a direct reclaimer woke kswapd within HZ/10, it's premature */
> >  	if (remaining)
> >  		return true;
> 
> I'm a bit worried by this one.
> 
> Do we really fully understand why kswapd is continuously running like
> this?  The changelog makes me think "no" ;)
> 
> Given that the page-allocating process is madly reclaiming pages in
> direct reclaim (yes?) and that kswapd is madly reclaiming pages on a
> different CPU, we should pretty promptly get into a situation where
> kswapd can suspend itself.  But that obviously isn't happening.  So
> what *is* going on?

The triggering workload is a massive untar using a file on the same
filesystem, so that's a continuous stream of pages read into the cache
for the input and a stream of dirty pages out for the writes.  We
thought it might have been out of control shrinkers, so we already
debugged that and found it wasn't.  It just seems to be an imbalance in
the zones that the shrinkers can't fix which causes
sleeping_prematurely() to return true almost indefinitely.

> Secondly, taking an up-to-100ms sleep in response to a need_resched()
> seems pretty savage and I suspect it risks undesirable side-effects.  A
> plain old cond_resched() would be more cautious.  But presumably
> kswapd() is already running cond_resched() pretty frequently, so why
> didn't that work?

So the specific problem with cond_resched() is that kswapd is still
runnable, so even if there's other work the system can be getting on
with, it quickly comes back to looping madly in kswapd.  If we return
false from sleeping_prematurely(), we stop kswapd until its woken up to
do more work.  This manifests, even on non sandybridge systems that
don't hang as a lot of time burned in kswapd.

I think the sandybridge bug I see on the laptop is that cond_resched()
is somehow ineffective:  kswapd is usually hogging one CPU and there are
runnable processes but they seem to cluster on other CPUs, leaving
kswapd to spin at close to 100% system time.

When the problem was first described, we tried sprinkling more
cond_rescheds() in the shrinker loop and it didn't work.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andrew Morton - May 17, 2011, 11:22 p.m.
On Tue, 17 May 2011 10:37:04 +0400
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Mon, 2011-05-16 at 14:16 -0700, Andrew Morton wrote:
> > On Mon, 16 May 2011 16:06:57 +0100
> > Mel Gorman <mgorman@suse.de> wrote:
> > 
> > > Under constant allocation pressure, kswapd can be in the situation where
> > > sleeping_prematurely() will always return true even if kswapd has been
> > > running a long time. Check if kswapd needs to be scheduled.
> > > 
> > > Signed-off-by: Mel Gorman <mgorman@suse.de>
> > > Acked-by: Rik van Riel <riel@redhat.com>
> > > ---
> > >  mm/vmscan.c |    4 ++++
> > >  1 files changed, 4 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index af24d1e..4d24828 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,
> > >  	unsigned long balanced = 0;
> > >  	bool all_zones_ok = true;
> > >  
> > > +	/* If kswapd has been running too long, just sleep */
> > > +	if (need_resched())
> > > +		return false;
> > > +
> > >  	/* If a direct reclaimer woke kswapd within HZ/10, it's premature */
> > >  	if (remaining)
> > >  		return true;
> > 
> > I'm a bit worried by this one.
> > 
> > Do we really fully understand why kswapd is continuously running like
> > this?  The changelog makes me think "no" ;)
> > 
> > Given that the page-allocating process is madly reclaiming pages in
> > direct reclaim (yes?) and that kswapd is madly reclaiming pages on a
> > different CPU, we should pretty promptly get into a situation where
> > kswapd can suspend itself.  But that obviously isn't happening.  So
> > what *is* going on?
> 
> The triggering workload is a massive untar using a file on the same
> filesystem, so that's a continuous stream of pages read into the cache
> for the input and a stream of dirty pages out for the writes.  We
> thought it might have been out of control shrinkers, so we already
> debugged that and found it wasn't.  It just seems to be an imbalance in
> the zones that the shrinkers can't fix which causes
> sleeping_prematurely() to return true almost indefinitely.

Is the untar disk-bound?  The untar has presumably hit the writeback
dirty_ratio?  So its rate of page allocation is approximately equal to
the write speed of the disks?

If so, the VM is consuming 100% of a CPU to reclaim pages at a mere
tens-of-megabytes-per-second.  If so, there's something seriously wrong
here - under favorable conditions one would expect reclaim to free up
100,000 pages/sec, maybe more.

If the untar is not disk-bound and the required page reclaim rate is
equal to the rate at which a CPU can read, decompress and write to
pagecache then, err, maybe possible.  But it still smells of
inefficient reclaim.

> > Secondly, taking an up-to-100ms sleep in response to a need_resched()
> > seems pretty savage and I suspect it risks undesirable side-effects.  A
> > plain old cond_resched() would be more cautious.  But presumably
> > kswapd() is already running cond_resched() pretty frequently, so why
> > didn't that work?
> 
> So the specific problem with cond_resched() is that kswapd is still
> runnable, so even if there's other work the system can be getting on
> with, it quickly comes back to looping madly in kswapd.  If we return
> false from sleeping_prematurely(), we stop kswapd until its woken up to
> do more work.  This manifests, even on non sandybridge systems that
> don't hang as a lot of time burned in kswapd.
> 
> I think the sandybridge bug I see on the laptop is that cond_resched()
> is somehow ineffective:  kswapd is usually hogging one CPU and there are
> runnable processes but they seem to cluster on other CPUs, leaving
> kswapd to spin at close to 100% system time.
> 
> When the problem was first described, we tried sprinkling more
> cond_rescheds() in the shrinker loop and it didn't work.

Seems to me that kswapd for some reason is doing too much work.  Or,
more specifically is doing its work very inefficiently.  Making kswapd
take arbitrary naps when it's misbehaving didn't fix that misbehaviour!

It would be interesting to watch kswapd's page reclaim inefficiency
when this is happening: /proc/vmstat:pgscan_kswapd_* versus
/proc/vmstat:kswapd_steal.  If that ration is high then kswapd is
scanning many pages and not reclaiming them.

But given the prominence of shrink_slab in the traces, perhaps that
isn't happening.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mel Gorman - May 18, 2011, 9:47 a.m.
On Tue, May 17, 2011 at 04:22:26PM -0700, Andrew Morton wrote:
> On Tue, 17 May 2011 10:37:04 +0400
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > On Mon, 2011-05-16 at 14:16 -0700, Andrew Morton wrote:
> > > On Mon, 16 May 2011 16:06:57 +0100
> > > Mel Gorman <mgorman@suse.de> wrote:
> > > 
> > > > Under constant allocation pressure, kswapd can be in the situation where
> > > > sleeping_prematurely() will always return true even if kswapd has been
> > > > running a long time. Check if kswapd needs to be scheduled.
> > > > 
> > > > Signed-off-by: Mel Gorman <mgorman@suse.de>
> > > > Acked-by: Rik van Riel <riel@redhat.com>
> > > > ---
> > > >  mm/vmscan.c |    4 ++++
> > > >  1 files changed, 4 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > index af24d1e..4d24828 100644
> > > > --- a/mm/vmscan.c
> > > > +++ b/mm/vmscan.c
> > > > @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,
> > > >  	unsigned long balanced = 0;
> > > >  	bool all_zones_ok = true;
> > > >  
> > > > +	/* If kswapd has been running too long, just sleep */
> > > > +	if (need_resched())
> > > > +		return false;
> > > > +
> > > >  	/* If a direct reclaimer woke kswapd within HZ/10, it's premature */
> > > >  	if (remaining)
> > > >  		return true;
> > > 
> > > I'm a bit worried by this one.
> > > 
> > > Do we really fully understand why kswapd is continuously running like
> > > this?  The changelog makes me think "no" ;)
> > > 
> > > Given that the page-allocating process is madly reclaiming pages in
> > > direct reclaim (yes?) and that kswapd is madly reclaiming pages on a
> > > different CPU, we should pretty promptly get into a situation where
> > > kswapd can suspend itself.  But that obviously isn't happening.  So
> > > what *is* going on?
> > 
> > The triggering workload is a massive untar using a file on the same
> > filesystem, so that's a continuous stream of pages read into the cache
> > for the input and a stream of dirty pages out for the writes.  We
> > thought it might have been out of control shrinkers, so we already
> > debugged that and found it wasn't.  It just seems to be an imbalance in
> > the zones that the shrinkers can't fix which causes
> > sleeping_prematurely() to return true almost indefinitely.
> 
> Is the untar disk-bound?  The untar has presumably hit the writeback
> dirty_ratio?  So its rate of page allocation is approximately equal to
> the write speed of the disks?
> 

A reasonable assumption but it gets messy.

> If so, the VM is consuming 100% of a CPU to reclaim pages at a mere
> tens-of-megabytes-per-second.  If so, there's something seriously wrong
> here - under favorable conditions one would expect reclaim to free up
> 100,000 pages/sec, maybe more.
> 
> If the untar is not disk-bound and the required page reclaim rate is
> equal to the rate at which a CPU can read, decompress and write to
> pagecache then, err, maybe possible.  But it still smells of
> inefficient reclaim.
> 

I think it's higher than just the rate of data but couldn't guess by
how much exactly. Reproducing this locally would have been nice but
the following conditions are likely happening on the problem machine.

   SLUB is using high-orders for its slabs, kswapd and reclaimers are
   reclaiming at a faster rate than required for just the data. SLUB
   is using order-2 allocs for inodes so every 18 files created by
   untar, we need an order-2 page. For ext4_io_end, we need order-3
   allocs and we are allocating these due to delayed block allocation.

   So for example: 50 files, each less than 1 page in size needs 50
   order-0 pages, 3 order-2 page and 2 order-3 pages

   To satisfy the high order pages, we are reclaiming at least 28
   pages. For compaction, we are migrating these so we are allocating
   a further 28 pages and then copying putting further pressure on
   the system. We may do this multiple times as order-0 allocations
   could be breaking up the pages again. Without compaction, we are
   only reclaiming but can get stalled for significant periods of
   time if dirty or writeback pages are encountered in the contiguous
   blocks and can reclaim too many pages quite easily.

So the rate of allocation required to write out data is higher than
just the data rate. The reclaim rate could be just fine but the number
of pages we need to reclaim to allocate slab objects can be screwy.

> > > Secondly, taking an up-to-100ms sleep in response to a need_resched()
> > > seems pretty savage and I suspect it risks undesirable side-effects.  A
> > > plain old cond_resched() would be more cautious.  But presumably
> > > kswapd() is already running cond_resched() pretty frequently, so why
> > > didn't that work?
> > 
> > So the specific problem with cond_resched() is that kswapd is still
> > runnable, so even if there's other work the system can be getting on
> > with, it quickly comes back to looping madly in kswapd.  If we return
> > false from sleeping_prematurely(), we stop kswapd until its woken up to
> > do more work.  This manifests, even on non sandybridge systems that
> > don't hang as a lot of time burned in kswapd.
> > 
> > I think the sandybridge bug I see on the laptop is that cond_resched()
> > is somehow ineffective:  kswapd is usually hogging one CPU and there are
> > runnable processes but they seem to cluster on other CPUs, leaving
> > kswapd to spin at close to 100% system time.
> > 
> > When the problem was first described, we tried sprinkling more
> > cond_rescheds() in the shrinker loop and it didn't work.
> 
> Seems to me that kswapd for some reason is doing too much work.  Or,
> more specifically is doing its work very inefficiently.  Making kswapd
> take arbitrary naps when it's misbehaving didn't fix that misbehaviour!
> 

It is likely to be doing work inefficiently in one of two ways

  1. We are reclaiming far more pages than required by the data
     for slab objects

  2. The rate we are reclaiming is fast enough that dirty pages are
     reaching the end of the LRU quickly

The latter part is also important. I doubt we are getting stalled in
writepage as this is new data being written to disk to blocks aren't
allocated yet but kswapd is encountering the dirty_ratio of pages
on the LRU and churning them through the LRU and reclaims the clean
pages in between.

In effect, this "sorts" the LRU lists so the dirty pages get grouped
together. At worst on a 2G system such as James', we have 104857
(20% of memory in pages) pages together on the LRU, all dirty and
all being skipped over by kswapd and direct reclaimers. This is at
least 3276 takings of the zone LRU lock assuming we isolate pages in
groups of SWAP_CLUSTER_MAX which a lot of list walking and CPU usage
for no pages reclaimed.

In this case, kswapd might as well take a brief nap as it can't clean
the pages so the flusher threads can get some work done.

> It would be interesting to watch kswapd's page reclaim inefficiency
> when this is happening: /proc/vmstat:pgscan_kswapd_* versus
> /proc/vmstat:kswapd_steal.  If that ration is high then kswapd is
> scanning many pages and not reclaiming them.
> 
> But given the prominence of shrink_slab in the traces, perhaps that
> isn't happening.
> 

As we are aggressively shrinking slab, we can reach the stage where
we scan the requested number of objects and reclaim none of them
potentially setting zone->all_unreclaimable to 1 if a lot of scanning
has also taken place recently without pages being freed. Once this
happens, kswapd isn't even trying to reclaim pages and is instead stuck
in shrink_slab until a page is freed clearing zone->all_unreclaimable
and zone->pages-scanned.

The ratio during that window would not change but slabs_scanned would
continue to increase.
MinChan Kim - May 18, 2011, 10:42 p.m.
On Wed, May 18, 2011 at 6:47 PM, Mel Gorman <mgorman@suse.de> wrote:
> On Tue, May 17, 2011 at 04:22:26PM -0700, Andrew Morton wrote:
>> On Tue, 17 May 2011 10:37:04 +0400
>> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>>
>> > On Mon, 2011-05-16 at 14:16 -0700, Andrew Morton wrote:
>> > > On Mon, 16 May 2011 16:06:57 +0100
>> > > Mel Gorman <mgorman@suse.de> wrote:
>> > >
>> > > > Under constant allocation pressure, kswapd can be in the situation where
>> > > > sleeping_prematurely() will always return true even if kswapd has been
>> > > > running a long time. Check if kswapd needs to be scheduled.
>> > > >
>> > > > Signed-off-by: Mel Gorman <mgorman@suse.de>
>> > > > Acked-by: Rik van Riel <riel@redhat.com>
>> > > > ---
>> > > >  mm/vmscan.c |    4 ++++
>> > > >  1 files changed, 4 insertions(+), 0 deletions(-)
>> > > >
>> > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
>> > > > index af24d1e..4d24828 100644
>> > > > --- a/mm/vmscan.c
>> > > > +++ b/mm/vmscan.c
>> > > > @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,
>> > > >         unsigned long balanced = 0;
>> > > >         bool all_zones_ok = true;
>> > > >
>> > > > +       /* If kswapd has been running too long, just sleep */
>> > > > +       if (need_resched())
>> > > > +               return false;
>> > > > +
>> > > >         /* If a direct reclaimer woke kswapd within HZ/10, it's premature */
>> > > >         if (remaining)
>> > > >                 return true;
>> > >
>> > > I'm a bit worried by this one.
>> > >
>> > > Do we really fully understand why kswapd is continuously running like
>> > > this?  The changelog makes me think "no" ;)
>> > >
>> > > Given that the page-allocating process is madly reclaiming pages in
>> > > direct reclaim (yes?) and that kswapd is madly reclaiming pages on a
>> > > different CPU, we should pretty promptly get into a situation where
>> > > kswapd can suspend itself.  But that obviously isn't happening.  So
>> > > what *is* going on?
>> >
>> > The triggering workload is a massive untar using a file on the same
>> > filesystem, so that's a continuous stream of pages read into the cache
>> > for the input and a stream of dirty pages out for the writes.  We
>> > thought it might have been out of control shrinkers, so we already
>> > debugged that and found it wasn't.  It just seems to be an imbalance in
>> > the zones that the shrinkers can't fix which causes
>> > sleeping_prematurely() to return true almost indefinitely.
>>
>> Is the untar disk-bound?  The untar has presumably hit the writeback
>> dirty_ratio?  So its rate of page allocation is approximately equal to
>> the write speed of the disks?
>>
>
> A reasonable assumption but it gets messy.
>
>> If so, the VM is consuming 100% of a CPU to reclaim pages at a mere
>> tens-of-megabytes-per-second.  If so, there's something seriously wrong
>> here - under favorable conditions one would expect reclaim to free up
>> 100,000 pages/sec, maybe more.
>>
>> If the untar is not disk-bound and the required page reclaim rate is
>> equal to the rate at which a CPU can read, decompress and write to
>> pagecache then, err, maybe possible.  But it still smells of
>> inefficient reclaim.
>>
>
> I think it's higher than just the rate of data but couldn't guess by
> how much exactly. Reproducing this locally would have been nice but
> the following conditions are likely happening on the problem machine.
>
>   SLUB is using high-orders for its slabs, kswapd and reclaimers are
>   reclaiming at a faster rate than required for just the data. SLUB
>   is using order-2 allocs for inodes so every 18 files created by
>   untar, we need an order-2 page. For ext4_io_end, we need order-3
>   allocs and we are allocating these due to delayed block allocation.
>
>   So for example: 50 files, each less than 1 page in size needs 50
>   order-0 pages, 3 order-2 page and 2 order-3 pages
>
>   To satisfy the high order pages, we are reclaiming at least 28
>   pages. For compaction, we are migrating these so we are allocating
>   a further 28 pages and then copying putting further pressure on
>   the system. We may do this multiple times as order-0 allocations
>   could be breaking up the pages again. Without compaction, we are
>   only reclaiming but can get stalled for significant periods of
>   time if dirty or writeback pages are encountered in the contiguous
>   blocks and can reclaim too many pages quite easily.
>
> So the rate of allocation required to write out data is higher than
> just the data rate. The reclaim rate could be just fine but the number
> of pages we need to reclaim to allocate slab objects can be screwy.
>
>> > > Secondly, taking an up-to-100ms sleep in response to a need_resched()
>> > > seems pretty savage and I suspect it risks undesirable side-effects.  A
>> > > plain old cond_resched() would be more cautious.  But presumably
>> > > kswapd() is already running cond_resched() pretty frequently, so why
>> > > didn't that work?
>> >
>> > So the specific problem with cond_resched() is that kswapd is still
>> > runnable, so even if there's other work the system can be getting on
>> > with, it quickly comes back to looping madly in kswapd.  If we return
>> > false from sleeping_prematurely(), we stop kswapd until its woken up to
>> > do more work.  This manifests, even on non sandybridge systems that
>> > don't hang as a lot of time burned in kswapd.
>> >
>> > I think the sandybridge bug I see on the laptop is that cond_resched()
>> > is somehow ineffective:  kswapd is usually hogging one CPU and there are
>> > runnable processes but they seem to cluster on other CPUs, leaving
>> > kswapd to spin at close to 100% system time.
>> >
>> > When the problem was first described, we tried sprinkling more
>> > cond_rescheds() in the shrinker loop and it didn't work.
>>
>> Seems to me that kswapd for some reason is doing too much work.  Or,
>> more specifically is doing its work very inefficiently.  Making kswapd
>> take arbitrary naps when it's misbehaving didn't fix that misbehaviour!
>>
>
> It is likely to be doing work inefficiently in one of two ways
>
>  1. We are reclaiming far more pages than required by the data
>     for slab objects
>
>  2. The rate we are reclaiming is fast enough that dirty pages are
>     reaching the end of the LRU quickly
>
> The latter part is also important. I doubt we are getting stalled in
> writepage as this is new data being written to disk to blocks aren't
> allocated yet but kswapd is encountering the dirty_ratio of pages
> on the LRU and churning them through the LRU and reclaims the clean
> pages in between.
>
> In effect, this "sorts" the LRU lists so the dirty pages get grouped
> together. At worst on a 2G system such as James', we have 104857
> (20% of memory in pages) pages together on the LRU, all dirty and
> all being skipped over by kswapd and direct reclaimers. This is at
> least 3276 takings of the zone LRU lock assuming we isolate pages in
> groups of SWAP_CLUSTER_MAX which a lot of list walking and CPU usage
> for no pages reclaimed.
>
> In this case, kswapd might as well take a brief nap as it can't clean
> the pages so the flusher threads can get some work done.
>
>> It would be interesting to watch kswapd's page reclaim inefficiency
>> when this is happening: /proc/vmstat:pgscan_kswapd_* versus
>> /proc/vmstat:kswapd_steal.  If that ration is high then kswapd is
>> scanning many pages and not reclaiming them.
>>
>> But given the prominence of shrink_slab in the traces, perhaps that
>> isn't happening.
>>
>
> As we are aggressively shrinking slab, we can reach the stage where
> we scan the requested number of objects and reclaim none of them
> potentially setting zone->all_unreclaimable to 1 if a lot of scanning
> has also taken place recently without pages being freed. Once this
> happens, kswapd isn't even trying to reclaim pages and is instead stuck
> in shrink_slab until a page is freed clearing zone->all_unreclaimable
> and zone->pages-scanned.

Why does it stuck in shrink_slab?
If the zone is trouble to reclaim(ie, all_unreclaimable is set),
kswapd will poll the zone only in case of DEF_PRIORITY(ie, small
window) for when the problem goes away. In high priority (0..11), the
zone will be skipped and we can't get a chance to call
shrink_[zone|slab].


>
> The ratio during that window would not change but slabs_scanned would
> continue to increase.
>
> --
> Mel Gorman
> SUSE Labs
>
Dave Chinner - May 19, 2011, 12:28 a.m.
On Wed, May 18, 2011 at 10:47:18AM +0100, Mel Gorman wrote:
> As we are aggressively shrinking slab, we can reach the stage where
> we scan the requested number of objects and reclaim none of them
> potentially setting zone->all_unreclaimable to 1 if a lot of scanning
> has also taken place recently without pages being freed. Once this
> happens, kswapd isn't even trying to reclaim pages and is instead stuck
> in shrink_slab until a page is freed clearing zone->all_unreclaimable
> and zone->pages-scanned.

Isn't this completely broken then? We can have slabs with lots of
objects but none are reclaimable - e.g. dirty inodes are not even on
the inode LRU and require IO to get there, so repeatedly scanning
the slab trying to free inodes is completely pointless.

If the shrinkers are not freeing anything, then it should be backing
off and giving thme some time to clean objects is a much more
efficient use of CPU time than spinning madly. Indeed, if you back
off, you can do another pass over the LRU and see if there are more
pages that can be reclaimed, too, so you're not dependent on the
shrinkers actually making progress to break the livelock....

Cheers,

Dave.
Mel Gorman - May 19, 2011, 9:19 a.m.
On Thu, May 19, 2011 at 07:42:29AM +0900, Minchan Kim wrote:
> On Wed, May 18, 2011 at 6:47 PM, Mel Gorman <mgorman@suse.de> wrote:
> > On Tue, May 17, 2011 at 04:22:26PM -0700, Andrew Morton wrote:
> >> On Tue, 17 May 2011 10:37:04 +0400
> >> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >>
> >> > On Mon, 2011-05-16 at 14:16 -0700, Andrew Morton wrote:
> >> > > On Mon, 16 May 2011 16:06:57 +0100
> >> > > Mel Gorman <mgorman@suse.de> wrote:
> >> > >
> >> > > > Under constant allocation pressure, kswapd can be in the situation where
> >> > > > sleeping_prematurely() will always return true even if kswapd has been
> >> > > > running a long time. Check if kswapd needs to be scheduled.
> >> > > >
> >> > > > Signed-off-by: Mel Gorman <mgorman@suse.de>
> >> > > > Acked-by: Rik van Riel <riel@redhat.com>
> >> > > > ---
> >> > > >  mm/vmscan.c |    4 ++++
> >> > > >  1 files changed, 4 insertions(+), 0 deletions(-)
> >> > > >
> >> > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> >> > > > index af24d1e..4d24828 100644
> >> > > > --- a/mm/vmscan.c
> >> > > > +++ b/mm/vmscan.c
> >> > > > @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,
> >> > > >         unsigned long balanced = 0;
> >> > > >         bool all_zones_ok = true;
> >> > > >
> >> > > > +       /* If kswapd has been running too long, just sleep */
> >> > > > +       if (need_resched())
> >> > > > +               return false;
> >> > > > +
> >> > > >         /* If a direct reclaimer woke kswapd within HZ/10, it's premature */
> >> > > >         if (remaining)
> >> > > >                 return true;
> >> > >
> >> > > I'm a bit worried by this one.
> >> > >
> >> > > Do we really fully understand why kswapd is continuously running like
> >> > > this?  The changelog makes me think "no" ;)
> >> > >
> >> > > Given that the page-allocating process is madly reclaiming pages in
> >> > > direct reclaim (yes?) and that kswapd is madly reclaiming pages on a
> >> > > different CPU, we should pretty promptly get into a situation where
> >> > > kswapd can suspend itself.  But that obviously isn't happening.  So
> >> > > what *is* going on?
> >> >
> >> > The triggering workload is a massive untar using a file on the same
> >> > filesystem, so that's a continuous stream of pages read into the cache
> >> > for the input and a stream of dirty pages out for the writes.  We
> >> > thought it might have been out of control shrinkers, so we already
> >> > debugged that and found it wasn't.  It just seems to be an imbalance in
> >> > the zones that the shrinkers can't fix which causes
> >> > sleeping_prematurely() to return true almost indefinitely.
> >>
> >> Is the untar disk-bound?  The untar has presumably hit the writeback
> >> dirty_ratio?  So its rate of page allocation is approximately equal to
> >> the write speed of the disks?
> >>
> >
> > A reasonable assumption but it gets messy.
> >
> >> If so, the VM is consuming 100% of a CPU to reclaim pages at a mere
> >> tens-of-megabytes-per-second.  If so, there's something seriously wrong
> >> here - under favorable conditions one would expect reclaim to free up
> >> 100,000 pages/sec, maybe more.
> >>
> >> If the untar is not disk-bound and the required page reclaim rate is
> >> equal to the rate at which a CPU can read, decompress and write to
> >> pagecache then, err, maybe possible.  But it still smells of
> >> inefficient reclaim.
> >>
> >
> > I think it's higher than just the rate of data but couldn't guess by
> > how much exactly. Reproducing this locally would have been nice but
> > the following conditions are likely happening on the problem machine.
> >
> >   SLUB is using high-orders for its slabs, kswapd and reclaimers are
> >   reclaiming at a faster rate than required for just the data. SLUB
> >   is using order-2 allocs for inodes so every 18 files created by
> >   untar, we need an order-2 page. For ext4_io_end, we need order-3
> >   allocs and we are allocating these due to delayed block allocation.
> >
> >   So for example: 50 files, each less than 1 page in size needs 50
> >   order-0 pages, 3 order-2 page and 2 order-3 pages
> >
> >   To satisfy the high order pages, we are reclaiming at least 28
> >   pages. For compaction, we are migrating these so we are allocating
> >   a further 28 pages and then copying putting further pressure on
> >   the system. We may do this multiple times as order-0 allocations
> >   could be breaking up the pages again. Without compaction, we are
> >   only reclaiming but can get stalled for significant periods of
> >   time if dirty or writeback pages are encountered in the contiguous
> >   blocks and can reclaim too many pages quite easily.
> >
> > So the rate of allocation required to write out data is higher than
> > just the data rate. The reclaim rate could be just fine but the number
> > of pages we need to reclaim to allocate slab objects can be screwy.
> >
> >> > > Secondly, taking an up-to-100ms sleep in response to a need_resched()
> >> > > seems pretty savage and I suspect it risks undesirable side-effects.  A
> >> > > plain old cond_resched() would be more cautious.  But presumably
> >> > > kswapd() is already running cond_resched() pretty frequently, so why
> >> > > didn't that work?
> >> >
> >> > So the specific problem with cond_resched() is that kswapd is still
> >> > runnable, so even if there's other work the system can be getting on
> >> > with, it quickly comes back to looping madly in kswapd.  If we return
> >> > false from sleeping_prematurely(), we stop kswapd until its woken up to
> >> > do more work.  This manifests, even on non sandybridge systems that
> >> > don't hang as a lot of time burned in kswapd.
> >> >
> >> > I think the sandybridge bug I see on the laptop is that cond_resched()
> >> > is somehow ineffective:  kswapd is usually hogging one CPU and there are
> >> > runnable processes but they seem to cluster on other CPUs, leaving
> >> > kswapd to spin at close to 100% system time.
> >> >
> >> > When the problem was first described, we tried sprinkling more
> >> > cond_rescheds() in the shrinker loop and it didn't work.
> >>
> >> Seems to me that kswapd for some reason is doing too much work.  Or,
> >> more specifically is doing its work very inefficiently.  Making kswapd
> >> take arbitrary naps when it's misbehaving didn't fix that misbehaviour!
> >>
> >
> > It is likely to be doing work inefficiently in one of two ways
> >
> >  1. We are reclaiming far more pages than required by the data
> >     for slab objects
> >
> >  2. The rate we are reclaiming is fast enough that dirty pages are
> >     reaching the end of the LRU quickly
> >
> > The latter part is also important. I doubt we are getting stalled in
> > writepage as this is new data being written to disk to blocks aren't
> > allocated yet but kswapd is encountering the dirty_ratio of pages
> > on the LRU and churning them through the LRU and reclaims the clean
> > pages in between.
> >
> > In effect, this "sorts" the LRU lists so the dirty pages get grouped
> > together. At worst on a 2G system such as James', we have 104857
> > (20% of memory in pages) pages together on the LRU, all dirty and
> > all being skipped over by kswapd and direct reclaimers. This is at
> > least 3276 takings of the zone LRU lock assuming we isolate pages in
> > groups of SWAP_CLUSTER_MAX which a lot of list walking and CPU usage
> > for no pages reclaimed.
> >
> > In this case, kswapd might as well take a brief nap as it can't clean
> > the pages so the flusher threads can get some work done.
> >
> >> It would be interesting to watch kswapd's page reclaim inefficiency
> >> when this is happening: /proc/vmstat:pgscan_kswapd_* versus
> >> /proc/vmstat:kswapd_steal.  If that ration is high then kswapd is
> >> scanning many pages and not reclaiming them.
> >>
> >> But given the prominence of shrink_slab in the traces, perhaps that
> >> isn't happening.
> >>
> >
> > As we are aggressively shrinking slab, we can reach the stage where
> > we scan the requested number of objects and reclaim none of them
> > potentially setting zone->all_unreclaimable to 1 if a lot of scanning
> > has also taken place recently without pages being freed. Once this
> > happens, kswapd isn't even trying to reclaim pages and is instead stuck
> > in shrink_slab until a page is freed clearing zone->all_unreclaimable
> > and zone->pages-scanned.
> 
> Why does it stuck in shrink_slab?
> If the zone is trouble to reclaim(ie, all_unreclaimable is set),
> kswapd will poll the zone only in case of DEF_PRIORITY(ie, small
> window) for when the problem goes away.

"stuck in shrink" was a poor choice of words. I should have said we
can spend a lot of time in there.

True, kswapd will only poll the zones while all_unreclaimable is
set but it only takes one page to be freed to the per-cpu list to
clear all_unreclaimable again. Once any zone has all_unreclaimable
cleared, the watermarks are checked but with enough direct
reclaimers, it's possible watermarks are met so shrink_zone is not
called but shrink_slab is called anyway. Depending on the result,
all_unreclaimable can get set again (possibly incorrectly as there
is simply no reclaimable slab objects rather than the zone is truely
unreclaimable). Another scenario is all zones except ZONE_DMA have
all_unreclaimable set when kswapd runs. kswapd finds the watermarks
to be ok as the zone is only lightly used so skips shrink_zone()
but calls shrink_slab() anyway.

Both of these situations would allow kswapd to use a lot of CPU while
spending a significant percentage of it in shrink_slab().

Patch

diff --git a/mm/vmscan.c b/mm/vmscan.c
index af24d1e..4d24828 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2251,6 +2251,10 @@  static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,
 	unsigned long balanced = 0;
 	bool all_zones_ok = true;
 
+	/* If kswapd has been running too long, just sleep */
+	if (need_resched())
+		return false;
+
 	/* If a direct reclaimer woke kswapd within HZ/10, it's premature */
 	if (remaining)
 		return true;