----- On Jan 21, 2020, at 4:44 PM, Chris Lameter cl@xxxxxxxxx wrote: > These scenarios are all pretty complex and will be difficult to understand > for the user of these APIs. > > I think the easiest solution (and most comprehensible) is for the user > space process that does per cpu operations to get some sort of signal. If > its not able to handle that then terminate it. The code makes a basic > assumption after all that the process is running on a specific cpu. If > this is no longer the case then its better to abort if the process cannot > handle moving to a different processor. The point of pin_on_cpu() is to allow threads to access per-cpu data structures belonging to a given CPU even if they cannot run on that CPU (because it is offline). I am not sure what scenario your signal delivery proposal aims to cover. Just to try to put this into the context of a specific scenario to see if I understand your point, is the following what you have in mind ? 1. Thread A issues pin_on_cpu(5), 2. Thread B issues sched_setaffinity removing cpu 5 from thread A's affinity mask, 3. Noticing that it would generate an invalid combination, rather than failing sched_setaffinity, it would send a SIGSEGV (or other) signal to thread A. Or so you have something entirely different in mind ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
