On Fri, 9 Jun 2000, James Sutherland wrote:
> On Fri, 9 Jun 2000, Tigran Aivazian wrote:
>
> > yes, there is - the lack of ability to bind a userspace process to a CPU
> > is the main reason why I implemented it differently from the other
> > "classical" implementations.
>
> 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...
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 ...
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/
- 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