> It is racey to do this, so its something that should remain a hack and
> not part of taskset, I think.
Hmm. I guess you are thinking of daemons?
> If you do it in rc.d, you don't need to set all the parents. rc.d is the
> first thing run, so if you do it at the top of the script, nothing else
> is running. Just put:
> taskset <mask> 1
> taskset <mask> $$
> at the top of rc.d.
Perhaps we are talking at cross purposes. As I understand it the calling chain
1. kernel bootstrap
3. bash to run /etc/rc.sysinit
4. bash to run individual /etc/rcN.d/whatever
I feel wary of doing it in 3 as you seem to suggest because I am pretty sure
this will intimidate my customers. I am happy to do it in 4 - I can avoid the
races by only doing it for the distros I care about.
That leaves options 1 and 2 for a community-wide solution. I guess I haven't
quite understood the reluctance to do it in 1 given that:
- we know who owns 1 (!!)
- AFAICS, it isn't conceptual bloat because the utility of the implementation
of sys_setaffinity() in 1 is greatly limited by not including this feature.
- its hardly physical bloat because the number of bytes required to implement
this is absolutely in the noise, and virtually all __init()ed away.
> Another consideration is modifying init (and hopefully having said
> changes merged back). Init could call sched_setaffinity() when it is
> first created, based on a setting in /etc/inittab or a command line
> parameter passed during boot.
I have no idea with whom to persue this path, and as I say, I feel that
solving this once for each distro is crazy IMHO.
> My reservation is against doing it in the kernel. I do not particularly
> care _how_ its done in user-space.
I'm sorry to appear foolish, but as explained above, I genuinely don't
understand why this does not belong in the kernel. I would be grateful for
elaboration. If I really am being thick, then just ignore me and I'll just
solve this for myself using route 4.
In any case, thanks for all the patience and kind suggestions so far - it is
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/