[lkml]   [2001]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] proc-based cpu affinity user interface
On Tue, 2001-11-27 at 01:25, Andreas Dilger wrote:
> On Nov 26, 2001 22:31 -0500, Robert Love wrote:
> > Reading and writing /proc/<pid>/affinity will get and set the affinity.
> >
> > Security is implemented: the writer must possess CAP_SYS_NICE or be the
> > same uid as the task in question. Anyone can read the data.
> Hmm, now that I think about it, anyone should be able to restrict the
> CPUs that their processes should run on, but like "nice", you should
> have CAP_SYS_NICE in order to increase the number of CPUs your process
> can run on. This makes it possible to "throttle" a user so that they
> can only max out a single CPU.
> Why would you do that? Maybe because "ulimit" and friends only allow
> you to set an absolute limit on the number of CPU seconds you can use
> per process, but not a "percentage" of a processor or some equivalent
> "cycles per second" unit.
> Not that I see this as being hugely necessary, but it may as well be
> consistent with current behaviour (c.f. nice, ulimit, etc, can all go
> down, but not necessarily up).

I thought about this too, and I realized that cpus_allowed is by default
0xffffffff (i.e., all procs in the system). That means this is only an
issue when the administrator explicitly changed affinity.

And that would occur in the situation you describe ... personally, I
think users should be able to set their masks but I completely see your

I suppose we could count the bits in cpus_allowed and make sure they are
less than or equal to the new_mask bits. This seems overkill, though.
We could just not allow users to change their own affinity without
CAP_SYS_NICE, and allow root to do anything (via CAP_SYS_ADMIN).

Anyone else have an opinion?

Robert Love

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.209 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site