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@xxxxxxxxx>.
>
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
