linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Hillf Danton <hdanton@sina.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6 v2] mm: Drain LRUs upon resume to userspace on nohz_full CPUs
Date: Mon, 10 Feb 2025 12:46:44 +0100	[thread overview]
Message-ID: <Z6nnJEpL8pPVtvAj@localhost.localdomain> (raw)
In-Reply-To: <20250210105028.2134-1-hdanton@sina.com>

Le Mon, Feb 10, 2025 at 06:50:26PM +0800, Hillf Danton a écrit :
> On Sun,  9 Feb 2025 23:30:04 +0100 Frederic Weisbecker <frederic@kernel.org>
> > @@ -769,6 +772,9 @@ static bool cpu_needs_drain(unsigned int cpu)
> >  {
> >  	struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu);
> >  
> > +	if (!housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE))
> > +		return false;
> > +
> >  	/* Check these in order of likelihood that they're not zero */
> >  	return folio_batch_count(&fbatches->lru_add) ||
> >  		folio_batch_count(&fbatches->lru_move_tail) ||
> > -- 
> > 2.46.0
> 
> Nit, I'd like to add a debug line to test your assumption that
> isolated tasks are pinned to a single nohz_full CPU.
> 
> --- x/mm/swap.c
> +++ y/mm/swap.c
> @@ -767,9 +767,10 @@ static void lru_add_drain_per_cpu(struct
>  static bool cpu_needs_drain(unsigned int cpu)
>  {
>  	struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu);
> +	bool yes;
>  
>  	/* Check these in order of likelihood that they're not zero */
> -	return folio_batch_count(&fbatches->lru_add) ||
> +	yes = folio_batch_count(&fbatches->lru_add) ||
>  		folio_batch_count(&fbatches->lru_move_tail) ||
>  		folio_batch_count(&fbatches->lru_deactivate_file) ||
>  		folio_batch_count(&fbatches->lru_deactivate) ||
> @@ -777,6 +778,12 @@ static bool cpu_needs_drain(unsigned int
>  		folio_batch_count(&fbatches->lru_activate) ||
>  		need_mlock_drain(cpu) ||
>  		has_bh_in_lru(cpu, NULL);
> +
> +	if (!housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE)) {
> +		VM_BUG_ON(yes);
> +		return false;
> +	}
> +	return yes;

If the task isn't pinned then the guarantees of nohz_full are broken anyway.
Also if the task migrates it will simply execute the work elsewhere.

My only worry is kernel threads. Those are simply ignored in this patchset but
this is not right as they can do allocations. Yet they can't execute anything
on return to userspace...

Thoughts?

Thanks.

>  }
>  
>  /*
> 


  parent reply	other threads:[~2025-02-10 11:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-09 22:29 [PATCH 0/6 v2] mm: LRU drain flush on nohz_full Frederic Weisbecker
2025-02-09 22:29 ` [PATCH 1/6 v2] task_work: Provide means to check if a work is queued Frederic Weisbecker
2025-02-10 12:43   ` Oleg Nesterov
2025-03-25 14:25     ` Frederic Weisbecker
2025-02-27 16:25   ` Valentin Schneider
2025-02-09 22:30 ` [PATCH 2/6 v2] sched/fair: Use task_work_queued() on numa_work Frederic Weisbecker
2025-02-10 12:47   ` Oleg Nesterov
2025-02-27 16:25   ` Valentin Schneider
2025-02-09 22:30 ` [PATCH 3/6 v2] sched: Use task_work_queued() on cid_work Frederic Weisbecker
2025-02-10 12:49   ` Oleg Nesterov
2025-02-09 22:30 ` [PATCH 4/6 v2] tick/nohz: Move nohz_full related fields out of hot task struct's places Frederic Weisbecker
2025-02-09 22:30 ` [PATCH 5/6 v2] sched/isolation: Introduce isolated task work Frederic Weisbecker
2025-02-09 22:30 ` [PATCH 6/6 v2] mm: Drain LRUs upon resume to userspace on nohz_full CPUs Frederic Weisbecker
2025-02-10 10:50   ` Hillf Danton
2025-02-10 11:19     ` Michal Hocko
2025-02-10 11:46     ` Frederic Weisbecker [this message]
2025-02-11 11:31       ` Hillf Danton
2025-02-11 11:42   ` Michal Hocko
2025-04-04 13:14     ` Frederic Weisbecker

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=Z6nnJEpL8pPVtvAj@localhost.localdomain \
    --to=frederic@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mtosatti@redhat.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;
as well as URLs for NNTP newsgroup(s).