[Toybox] new toy: taskset

[Rob Landley]

On 07/18/2012 02:53 AM, Elie De Brauwer wrote:
> On 07/18/2012 04:26 AM, Rob Landley wrote:
>> On 07/15/2012 06:34 AM, Elie De Brauwer wrote:
>>> Hello all,
>>>
>>> In attach you can find an initial version of 'taskset'. It allows
>>> setting the cpu affinity of a given PID (or all tasks related with a
>>> given PID/TID). cpu affinity should be entered in hex, when no affinity
>>> is given the affinity for the process or the group of tasks is
>>> displayed.
>>
>> Where did the -a flag come from?  The taskset on my system matches this
>> man page:
> 
> Whatever version of util-linux linux.die.net might 've stolen the
> manpage from, it for sure isn't a recent version.

I didn't mean to criticize, I'm just a bit frustrated trying to figure
out what the behavior should _be_ in the absence of a standard and with
implementations seeming to vary.

The man page I linked to matches the one on ubuntu 10.04, which is what
this netbook still has on it. (I'm being lazy about upgrading the LTS.
The new one has this horrible X11 behavior where clicks register twice a
lot of the time. They screwed up debouncing or something. _right_
clicking on things sometimes left-clicks what's underneath the mouse
cursor. Maybe it's an xfce thing, but I don't see how, and xubuntu 10.04
doesn't do it, so...)

> I just looked at the
> manpage on my debian system (util-linux-2.20.1) and it resembles this
> http://manpages.ubuntu.com/manpages/precise/man1/taskset.1.html  (you
> need to scroll down to see the options.
> (I think this patch http://www.digipedia.pl/usenet/thread/19513/138/
> more or less shows the -a specific changes).

So there's no standard for this command _and_ its changed significantly
in the past couple years. Lovely.

Ok, I happily defer to your superior knowledge in this area.

>>    http://linux.die.net/man/1/taskset
>>
>> In which taskset is a filter like nice, and -p says work on an existing
>> pid instead of launching a new one. I'd guess -a is the behavior it
>> always has, since "tasks" basically means "threads". (Unless containers
>> use that too...)
> 
> Indeed, except that if you use it with -p, the -a is not default (so it
> will only look at the tid specified).

Upstream behavior is crazy, but in the absence of a standard we follow
upstream behavior.  Got it.

>> I'm not sure whether to consider the man page's command line
>> grandfathered in (otherwise "taskset -p mask pid" won't work) or just go
>> ahead and make the pid an argument to -p. I _can_ implement either but
>> the current behavior makes no sense and there's no standard and your
>> submission didn't even match what was there so it's not like that's
>> _less_ compatible...
>>
> 
> Well, my submission matches (or at least was intended) to match
> taskset [-a] mask-in-hex pid

Ok.

> Meaning to works as renice, rather than nice. I'm open to suggestions, I
> can as well the 'work-as-nice' functionality,

Is there more to it than:

  if (opt.argc>2) xexec(toys.optargs+2);

Well, taskset getpid() and then exec. And detect -p... ok there's a bit
of work.

I'd prefer if you could add the new work-as-nice stuff since you know
what the UI should be like, and I'll hold off converting to the raw
syscall until then. Sound good?

Thanks,

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1342662081.0