Re: [patch] sched_[set|get]_affinity() syscall, 2.4.15-pre9

Ryan Cumming
2001-11-23T00:21:14Z

On November 22, 2001 15:45, Robert Love wrote:
>
> Ie, we would have a /proc/<pid>/cpu_affinity which is the same as your
> `unsigned long * user_mask_ptr'. Reading and writing of the proc
> interface would correspond to your get and set syscalls. Besides the
> sort of relevancy and useful abstraction of putting the affinity in the
> procfs, it eliminates any sizeof(cpus_allowed) problem since the read
> string is the size in characters of cpus_allowed.
>
> I would use your syscall code, though -- just reimplement it as a procfs
> file. This would mean adding a proc_write function, since the _actual_
> procfs (the proc part) only has a read method, but that is simple.
>
> Thoughts?

Here here, I was just thinking "Well, I like the CPU affinity idea, but I
loathe syscall creep... I hope this Robert Love fellow says something about
that" as I read your email's header.

In addition to keeping the syscall table from being filled with very
specific, non-standard, and use-once syscalls, a /proc interface would allow
me to change the CPU affinity of processes that aren't {get, set}_affinity
aware (i.e., all Linux applications written up to this point). This isn't
very different from how it's possible to change a processes other scheduling
properties (priority, scheduler) from another process. Imagine if renice(8)
had to be implemented as attaching to a process and calling nice(2)... ick.

Also, as an application developer, I try to avoid conditionally compiled,
system-specific calls. I would have much less "cleanliness" objections
towards testing for the /proc/<pid>/cpu_affinity files existance and
conditionally writing to it. Compare this to the hacks some network servers
use to try to detect sendfile(2)'s presence at runtime, and you'll see what I
mean. Remember, everything is a file ;)

And one final thing... what sort of benifit does CPU affinity have if we
have the scheduler take in account CPU migration costs correctly? I can think
of a lot of corner cases, but in general, it seems to me that it's a lot more
sane to have the scheduler decide where processes belong. What if an
application with n threads, where n is less than the number of CPUs, has to
decide which CPUs to bind its threads to? What if a similar app, or another
instance of the same app, already decided to bind against the same set of
CPUs? The scheduler is stuck with an unfair scheduling load on those poor
CPUs, because the scheduling decision was moved away from where it really
should take place: the scheduler. I'm sure I'm missing something, though.

-Ryan