This patch applies cleanly to 2.4.3-ac3.
Changes to array.c expose cpus_allowed in proc/pid/stat.
PR_GET_RUNON and PR_SET_RUNON were done by Ingo and Dimitris. Added
MUSTRUN_PID and RUNANY_PID.
Also attached is runon and it's manpage.
Nick
In message <[email protected]> you write:
> Changes to array.c expose cpus_allowed in proc/pid/stat.
Call me old fashioned, but I prefer my bitmasks in hex.
Please also consider changing:
still_running:
c = goodness(prev, this_cpu, prev->active_mm);
next = prev;
to:
still_running:
if (prev & (1 << this_cpu)) {
c = goodness(prev, this_cpu, prev->active_mm);
next = prev;
}
Otherwise, you will keep scheduling a RT process forever on a
disallowed CPU on which it is already running. And even a non-RT
process will stick on its disallowed CPU as long as nothing else runs
there.
Learnt this the hard way from the hotplug CPU patch...
Rusty.
--
Premature optmztion is rt of all evl. --DK
> disallowed CPU on which it is already running. And even a non-RT
> process will stick on its disallowed CPU as long as nothing else runs
> there.
are we going to keep the cpus_allowed API? If we want the (IMHO) more
flexible sysmp() API - I'll finish the 2.4 port. If we are going to keep
cpus_allowed - I'll just abandon pset and sysmp.
Personally, I like sysmp() and the pset tools better, perhaps with a /proc
extension to it.
Tim Hockin wrote:
>
> > disallowed CPU on which it is already running. And even a non-RT
> > process will stick on its disallowed CPU as long as nothing else runs
> > there.
>
> are we going to keep the cpus_allowed API? If we want the (IMHO) more
> flexible sysmp() API - I'll finish the 2.4 port. If we are going to keep
> cpus_allowed - I'll just abandon pset and sysmp.
>
> Personally, I like sysmp() and the pset tools better, perhaps with a /proc
> extension to it.
http://www.uow.edu.au/~andrewm/linux/cpus_allowed.patch
Nick Pollitt writes:
> Changes to array.c expose cpus_allowed in proc/pid/stat.
...
> -%lu %lu %lu %lu %lu %lu %lu %lu %d %d\n",
> +%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu\n",
...
> - task->processor);
> + task->processor,
> + task->cpus_allowed);
This isn't good. While it might be reasonable to have
an 8*sizeof(long) processor limit in the kernel, it is
not OK to expose this in the API. The API's limit should
be insanely high, like 256 or more.