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

[Ryan Cumming]

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