Re: [PATCH] mm/vmscan.c: no need to double-check if free pages are under high-watermark

[Mel Gorman <mgorman@techsingularity.net>]

On Sat, Mar 26, 2022 at 03:50:22PM +0000, Wei Yang wrote:
> On Thu, Jan 06, 2022 at 12:57:58PM +0000, Mel Gorman wrote:
> >On Thu, Jan 06, 2022 at 09:03:34PM +0900, DaeRo Lee wrote:
> >> > > @@ -4355,7 +4355,7 @@ static enum zone_type kswapd_highest_zoneidx(pg_data_t *pgdat,
> >> > >  static void kswapd_try_to_sleep(pg_data_t *pgdat, int alloc_order, int reclaim_order,
> >> > >                               unsigned int highest_zoneidx)
> >> > >  {
> >> > > -     long remaining = 0;
> >> > > +     long remaining = ~0;
> >> > >       DEFINE_WAIT(wait);
> >> > >
> >> > >       if (freezing(current) || kthread_should_stop())
> >> >
> >> > While this does avoid calling prepare_kswapd_sleep() twice if the pgdat
> >> > is balanced on the first try, it then does not restore the vmstat
> >> > thresholds and doesn't call schedul() for kswapd to go to sleep.
> >> 
> >> I intended not to call prepare_kswapd_sleep() twice when the pgdat is NOT
> >> balanced on the first try:)
> >> 
> >
> >Stupid typo on my part.
> >
> >> > @@ -4406,11 +4412,11 @@ static void kswapd_try_to_sleep(pg_data_t *pgdat, int alloc_order, int reclaim_o
> >> >         }
> >> >
> >> >         /*
> >> > -        * After a short sleep, check if it was a premature sleep. If not, then
> >> > -        * go fully to sleep until explicitly woken up.
> >> > +        * If balanced to the high watermark, restore vmstat thresholds and
> >> > +        * kswapd goes to sleep. If kswapd remains awake, account whether
> >> > +        * the low or high watermark was hit quickly.
> >> >          */
> >> > -       if (!remaining &&
> >> > -           prepare_kswapd_sleep(pgdat, reclaim_order, highest_zoneidx)) {
> >> > +       if (balanced) {
> >> >                 trace_mm_vmscan_kswapd_sleep(pgdat->node_id);
> >> >
> >> >                 /*
> >> 
> >> But, I think what you did is more readable and nice.
> >> Thanks!
> >> 
> >
> >Feel free to pick it up, rerun your tests to ensure it's behaving as
> >expected and resend! Include something in the changelog about user-visible
> >effects if any (or a note saying that it reduces unnecssary overhead)
> >and resend with me added to the cc.
> >
> 
> Hi, All
> 
> Seems this thread stops here. I don't see following patch and current upstream
> doesn't include this change.
> 
> May I continue this? Of course, with author-ship from DaeRo Lee <skseofh@gmail.com>.
> 

I've no objections. When I said "Feel free to pick it up", I meant that
I was ok with you taking the patch and putting your team on it.

> Mel,
> 
> Would you mind suggesting some cases that I could do to see the effects from
> this change? Such as the overhead or throughput? Or what cases you expect?
> 

I don't have any suggestions on artificially triggering it. I had assumed
you had encountered the bug in practice and had a test case but it would
be ok to note that the patch is a theoretical fix based on code review.

-- 
Mel Gorman
SUSE Labs