Re: sysctl(7) knob to allow users to control CPU affinity
On Thu, 3 Nov 2011 03:33:02 -0400, Matthew Mondor wrote: i think the default should be changed, but user-specified affinity shouldn't be considered an absolute rule, just a preference. i'm not sure i understand exactly what sort of issue you're envisioning. I assumed there could be issues since pset(3) is restricted to the superuser (as well as pthread_setaffinity_np(3) now), but when rethinking about it I admit not seeing a problem as non-privileged processes cannot change the process priority beyond their class' priority. The only other case that comes to my mind would be a dmover(9) like system eventually reserving processor(s) for dedicated tasks, but I guess that in this case the reserved cores would simply be made unavailable in cpuctl(8)/pset(3)/etc... What do you mean? A unified resource control API for kernel and userland processes/LWPs? -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: sysctl(7) knob to allow users to control CPU affinity
On Thu, 03 Nov 2011 17:01:48 +1100 matthew green wrote: > > Since the default is to not allow affinity control, it's not of utmost > > importance, but it could allow a compromise between total restriction > > and total freedom... I have no objection to that sysctl personally. > > i think the default should be changed, but user-specified affinity > shouldn't be considered an absolute rule, just a preference. i'm not > sure i understand exactly what sort of issue you're envisioning. I assumed there could be issues since pset(3) is restricted to the superuser (as well as pthread_setaffinity_np(3) now), but when rethinking about it I admit not seeing a problem as non-privileged processes cannot change the process priority beyond their class' priority. The only other case that comes to my mind would be a dmover(9) like system eventually reserving processor(s) for dedicated tasks, but I guess that in this case the reserved cores would simply be made unavailable in cpuctl(8)/pset(3)/etc... -- Matt
re: sysctl(7) knob to allow users to control CPU affinity
> > Here's a proposal for a sysctl(7) knob to easily allow non-superusers to > > set the CPU affinity of processes and threads they own: > > > > security.secmodel.suser.usersetaffinity > > > > (ressembles the one already existing to allow for user mounts) > > > > Would it be acceptable to modify current secmodel_suser(9) to allow this? > > > > This issue comes regularly on various tech-* MLs, motivated by the fact > > that people expect this behavior based on what they encounter on other OS. i like this idea. i didn't read the patch. > Just out of curiosity, but is it possible for the superuser to still > reserve wanted CPU/cores, such that non-privileged users could, if that > sysctl is enabled, work with the non-reserved ones? Or, can the > sysadmin specify CPU/cores and/or limits for non-privileged users? > > Since the default is to not allow affinity control, it's not of utmost > importance, but it could allow a compromise between total restriction > and total freedom... I have no objection to that sysctl personally. i think the default should be changed, but user-specified affinity shouldn't be considered an absolute rule, just a preference. i'm not sure i understand exactly what sort of issue you're envisioning. .mrg.
Re: sysctl(7) knob to allow users to control CPU affinity
On Thu, 03 Nov 2011 01:50:49 +0100 Jean-Yves Migeon wrote: > Here's a proposal for a sysctl(7) knob to easily allow non-superusers to > set the CPU affinity of processes and threads they own: > > security.secmodel.suser.usersetaffinity > > (ressembles the one already existing to allow for user mounts) > > Would it be acceptable to modify current secmodel_suser(9) to allow this? > > This issue comes regularly on various tech-* MLs, motivated by the fact > that people expect this behavior based on what they encounter on other OS. Just out of curiosity, but is it possible for the superuser to still reserve wanted CPU/cores, such that non-privileged users could, if that sysctl is enabled, work with the non-reserved ones? Or, can the sysadmin specify CPU/cores and/or limits for non-privileged users? Since the default is to not allow affinity control, it's not of utmost importance, but it could allow a compromise between total restriction and total freedom... I have no objection to that sysctl personally. Thanks, -- Matt
