On Fri, 9 Jun 2000, Rik van Riel wrote:
> On Fri, 9 Jun 2000, James Sutherland wrote:
> >
> > This would be a nice feature to have in a few other contexts as
> > well; for a simple example, when I'm running SETI@home on my
> > machine, I really want one instance on each CPU. There's no
> > point in having two instances sharing a single CPU, while
> > another task uses the first; if I could lock one instance to
> > each CPU, there would be some performance increase.
>
> Not really. It would mean that the priority of the non-running
> SETI@home will increase (slightly) and that your running
> process will switch CPU when its priority gets lower than that
> of the non-running seti...
Not ideal. What I really want is a system whereby all the idle CPU time on
CPU #0 goes to SETI #0, and likewise CPU #1 and SETI #1 - i.e. just
prevent both SETIs trying to run on the same CPU at once.
If there is ANYTHING running on the system which could use that CPU time,
it's not idle - so SETI shouldn't get run in the first place.
> Of course this doesn't have to happen, but to be honest I think
> that the alternative is worse. Suppose that the seti on the
> "busy" cpu doesn't get run, and another process in the system
> needs a kernel lock that that seti happens to hold ... system
> activity will stall for quite a while until the calculation is
> over and the seti@home is able to proceed and release the lock.
> Which could take a long time ...
SETI should never be holding any locks across calculations etc. anyway,
though, surely?
Perhaps the best solution would be to add a scheduler policy of
SCHED_IDLE? Anyway, this is a little unlikely to make it into 2.4 any time
soon, so I'll take it off-list for now.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:19 EST