public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Valentin Schneider <vschneid@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [RFC PATCH 6/6] mm: Drain LRUs upon resume to userspace on nohz_full CPUs
Date: Thu, 4 Jul 2024 15:11:24 +0200	[thread overview]
Message-ID: <ZoaffMfFdEgs2N7o@tiehlicka> (raw)
In-Reply-To: <ZoVJhXcR26paUNhX@localhost.localdomain>

On Wed 03-07-24 14:52:21, Frederic Weisbecker wrote:
> Le Tue, Jun 25, 2024 at 04:20:01PM +0200, Michal Hocko a écrit :
> > On Tue 25-06-24 15:52:44, Frederic Weisbecker wrote:
> > > LRUs can be drained through several ways. One of them may add disturbances
> > > to isolated workloads while queuing a work at any time to any target,
> > > whether running in nohz_full mode or not.
> > > 
> > > Prevent from that on isolated tasks with draining LRUs upon resuming to
> > > userspace using the isolated task work framework.
> > > 
> > > It's worth noting that this is inherently racy against
> > > lru_add_drain_all() remotely queueing the per CPU drain work and
> > > therefore it prevents from the undesired disturbance only
> > > *most of the time*.
> > 
> > Can we simply not schedule flushing on remote CPUs and leave that to the
> > "return to the userspace" path?
> 
> Do you mean I should add a call on return to the userspace path or can
> I expect it to be drained at some point already?

I would make the particular per cpu cache to be drained on return to the
userspace.

> The other limitation with that task work thing is that if the task
> queueing the work actually goes to sleep and another task go on the CPU
> and does isolated work in userspace, the drain doesn't happen. Now whether
> that is a real problem or not, I have no idea.

Theoretically there is a problem because pages sitting on pcp LRU caches
cannot be migrated and some other operations will fail as well. But
practically speaking those pages should be mostly of interest to the
process allocating them most of the time. Page sharing between isolated
workloads sounds like a terrible idea to me. Maybe reality hits us in
this regards but we can deal with that when we learn about those
workloads.

So I wouldn't lose too much sleep over that. We are dealing with those
isolated workloads being broken by simple things like fork now because
that apparently adds pages on the pcp LRU cache and draining will happen
sooner or later (very often when the task is already running in the
userspace).

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2024-07-04 13:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25 13:52 [RFC PATCH 0/6] mm: LRU drain flush on nohz_full Frederic Weisbecker
2024-06-25 13:52 ` [RFC PATCH 1/6] task_work: Provide means to check if a work is queued Frederic Weisbecker
2024-06-25 14:15   ` Oleg Nesterov
2024-06-25 15:16     ` Oleg Nesterov
2024-07-03 12:42       ` Frederic Weisbecker
2024-07-03 12:41     ` Frederic Weisbecker
2024-07-16 13:00   ` Valentin Schneider
2024-06-25 13:52 ` [RFC PATCH 2/6] sched/fair: Use task_work_queued() on numa_work Frederic Weisbecker
2024-07-16 13:00   ` Valentin Schneider
2024-06-25 13:52 ` [RFC PATCH 3/6] sched: Use task_work_queued() on cid_work Frederic Weisbecker
2024-07-16 13:00   ` Valentin Schneider
2024-06-25 13:52 ` [RFC PATCH 4/6] tick/nohz: Move nohz_full related fields out of hot task struct's places Frederic Weisbecker
2024-06-25 13:52 ` [RFC PATCH 5/6] sched/isolation: Introduce isolated task work Frederic Weisbecker
2024-06-26 13:27   ` Vlastimil Babka
2024-07-03 12:47     ` Frederic Weisbecker
2024-06-25 13:52 ` [RFC PATCH 6/6] mm: Drain LRUs upon resume to userspace on nohz_full CPUs Frederic Weisbecker
2024-06-25 14:20   ` Michal Hocko
2024-06-26 13:16     ` Vlastimil Babka
2024-06-27  6:54       ` Michal Hocko
2024-07-03 12:52     ` Frederic Weisbecker
2024-07-04 13:11       ` Michal Hocko [this message]
2024-07-17 13:21         ` 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=ZoaffMfFdEgs2N7o@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=vschneid@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