External Email
----------------------------------------------------------------------
On Fri, Jan 29, 2021 at 08:55:20AM -0500, Nitesh Narayan Lal wrote:
On 1/28/21 3:01 PM, Thomas Gleixner wrote:
On Thu, Jan 28 2021 at 13:59, Marcelo Tosatti wrote:
Which I answered in an seperate mail :)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 :-)
So housekeeping_cpumask has multiple meanings. In this case:...
So as long as the meaning of the flags are respected, seemsYes. Stuff like the managed interrupts preference for housekeeping CPUs
alright.
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 fixedEverything with is not managed can be steered by user space.
in userspace ? (as Thomas suggested previously).
Thanks,
tglx
So, I think the conclusion here would be to revert the change made in
cpumask_local_spread via the patch:
- lib: Restrict cpumask_local_spread to housekeeping CPUs
Also, a similar case can be made for the rps patch that went in with
this:
- net: Restrict receive packets queuing to housekeeping CPUs
Yes, this is the userspace solution:
https://lkml.org/lkml/2021/1/22/815
Should have a kernel document with this info and examples
(the network queue configuration as well). Will
send something.
+ net: accept an empty mask in /sys/class/net/*/queues/rx-*/rps_cpus
I am not sure about the PCI patch as I don't think we can control that from
the userspace or maybe I am wrong?
You mean "lib: Restrict cpumask_local_spread to housekeeping CPUs" ?