[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZBBv/l6NshXFI8vW@tpad>
Date: Tue, 14 Mar 2023 10:00:46 -0300
From: Marcelo Tosatti <mtosatti@...hat.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Christoph Lameter <cl@...ux.com>,
Aaron Tomlin <atomlin@...mlin.com>,
Frederic Weisbecker <frederic@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Russell King <linux@...linux.org.uk>,
Huacai Chen <chenhuacai@...nel.org>,
Heiko Carstens <hca@...ux.ibm.com>, x86@...nel.org,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH v5 00/12] fold per-CPU vmstats remotely
On Tue, Mar 14, 2023 at 09:59:37AM -0300, Marcelo Tosatti wrote:
> > Why is that a problem? Out-of-sync stats shouldn't cause major problems.
> > Or can they?
>
> Consider SCHED_FIFO task that is polling the network queue (say
> testpmd).
>
> do {
> if (net_registers->state & DATA_AVAILABLE) {
> process_data)();
> }
> } while (!stopped);
>
> Since this task runs at SCHED_FIFO priority, kworker won't
> be scheduled to run (therefore per-CPU vmstats won't be
> flushed to global vmstats).
>
> Or, if testpmd runs at SCHED_OTHER, then the work item to
> flush per-CPU vmstats causes
>
> testpmd -> kworker
> kworker: flush per-CPU vmstats
> kworker -> testpmd
>
> And this might cause undesired latencies to the packets being
> processed by the testpmd task.
This problem is unrelated to the kswapd problem, but both are addressed
by the patchset.
Powered by blists - more mailing lists