linux-kernel - RE: [Intel-wired-lan] [iwl-next PATCH v4 2/3] idpf: convert workqueues to unbound

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MW4PR11MB5911FC818C1312F2B8692012BA182@MW4PR11MB5911.namprd11.prod.outlook.com>
Date: Tue, 14 Jan 2025 07:00:08 +0000
From: "Singh, Krishneil K" <krishneil.k.singh@...el.com>
To: Brian Vazquez <brianvv@...gle.com>, "Lobakin, Aleksander"
	<aleksander.lobakin@...el.com>
CC: Brian Vazquez <brianvv.kernel@...il.com>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, "Paolo
 Abeni" <pabeni@...hat.com>, "intel-wired-lan@...ts.osuosl.org"
	<intel-wired-lan@...ts.osuosl.org>, David Decotigny <decot@...gle.com>, Vivek
 Kumar <vivekmr@...gle.com>, "Singhai, Anjali" <anjali.singhai@...el.com>,
	"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Tantilov, Emil S"
	<emil.s.tantilov@...el.com>, Marco Leogrande <leogrande@...gle.com>, Manoj
 Vishwanathan <manojvishy@...gle.com>, "Keller, Jacob E"
	<jacob.e.keller@...el.com>, "Linga, Pavan Kumar"
	<pavan.kumar.linga@...el.com>
Subject: RE: [Intel-wired-lan] [iwl-next PATCH v4 2/3] idpf: convert
 workqueues to unbound


> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
> Brian Vazquez
> Sent: Monday, December 16, 2024 12:13 PM
> To: Lobakin, Aleksander <aleksander.lobakin@...el.com>
> Cc: Brian Vazquez <brianvv.kernel@...il.com>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@...el.com>; David S. Miller <davem@...emloft.net>;
> Eric Dumazet <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>;
> Paolo Abeni <pabeni@...hat.com>; intel-wired-lan@...ts.osuosl.org; David
> Decotigny <decot@...gle.com>; Vivek Kumar <vivekmr@...gle.com>;
> Singhai, Anjali <anjali.singhai@...el.com>; Samudrala, Sridhar
> <sridhar.samudrala@...el.com>; linux-kernel@...r.kernel.org;
> netdev@...r.kernel.org; Tantilov, Emil S <emil.s.tantilov@...el.com>; Marco
> Leogrande <leogrande@...gle.com>; Manoj Vishwanathan
> <manojvishy@...gle.com>; Keller, Jacob E <jacob.e.keller@...el.com>; Linga,
> Pavan Kumar <pavan.kumar.linga@...el.com>
> Subject: Re: [Intel-wired-lan] [iwl-next PATCH v4 2/3] idpf: convert
> workqueues to unbound
> 
> On Mon, Dec 16, 2024 at 1:11 PM Alexander Lobakin
> <aleksander.lobakin@...el.com> wrote:
> >
> > From: Brian Vazquez <brianvv@...gle.com>
> > Date: Mon, 16 Dec 2024 16:27:34 +0000
> >
> > > From: Marco Leogrande <leogrande@...gle.com>
> > >
> > > When a workqueue is created with `WQ_UNBOUND`, its work items are
> > > served by special worker-pools, whose host workers are not bound to
> > > any specific CPU. In the default configuration (i.e. when
> > > `queue_delayed_work` and friends do not specify which CPU to run the
> > > work item on), `WQ_UNBOUND` allows the work item to be executed on
> any
> > > CPU in the same node of the CPU it was enqueued on. While this
> > > solution potentially sacrifices locality, it avoids contention with
> > > other processes that might dominate the CPU time of the processor the
> > > work item was scheduled on.
> > >
> > > This is not just a theoretical problem: in a particular scenario
> > > misconfigured process was hogging most of the time from CPU0, leaving
> > > less than 0.5% of its CPU time to the kworker. The IDPF workqueues
> > > that were using the kworker on CPU0 suffered large completion delays
> > > as a result, causing performance degradation, timeouts and eventual
> > > system crash.
> >
> > Wasn't this inspired by [0]?
> >
> > [0]
> > https://lore.kernel.org/netdev/20241126035849.6441-11-
> milena.olech@...el.com
> 
> The root cause is exactly the same so I do see the similarity and I'm
> not surprised that both were addressed with a similar patch, we hit
> this problem some time ago and the first attempt to have this was in
> August [0].
> 
> [0]
> https://lore.kernel.org/netdev/20240813182747.1770032-4-
> manojvishy@...gle.com/
> 
> >
> > Thanks,
> > Olek
Tested-by: Krishneil Singh <krishneil.k.singh@...el.com>