[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h7n0de5a.fsf@nanos.tec.linutronix.de>
Date: Thu, 28 Jan 2021 21:01:37 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Marcelo Tosatti <mtosatti@...hat.com>,
Nitesh Narayan Lal <nitesh@...hat.com>
Cc: Robin Murphy <robin.murphy@....com>,
Nitesh Narayan Lal <nitesh@...hat.com>,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
frederic@...nel.org, juri.lelli@...hat.com, abelits@...vell.com,
bhelgaas@...gle.com, linux-pci@...r.kernel.org,
rostedt@...dmis.org, mingo@...nel.org, peterz@...radead.org,
davem@...emloft.net, akpm@...ux-foundation.org,
sfr@...b.auug.org.au, stephen@...workplumber.org,
rppt@...ux.vnet.ibm.com, jinyuqi@...wei.com,
zhangshaokun@...ilicon.com
Subject: Re: [Patch v4 1/3] lib: Restrict cpumask_local_spread to houskeeping CPUs
On Thu, Jan 28 2021 at 13:59, Marcelo Tosatti wrote:
>> The whole pile wants to be reverted. It's simply broken in several ways.
>
> I was asking for your comments on interaction with CPU hotplug :-)
Which I answered in an seperate mail :)
> So housekeeping_cpumask has multiple meanings. In this case:
...
> So as long as the meaning of the flags are respected, seems
> alright.
Yes. Stuff like the managed interrupts preference for housekeeping CPUs
when a affinity mask spawns housekeeping and isolated is perfectly
fine. It's well thought out and has no limitations.
> Nitesh, is there anything preventing this from being fixed
> in userspace ? (as Thomas suggested previously).
Everything with is not managed can be steered by user space.
Thanks,
tglx
Powered by blists - more mailing lists