this would be someth. like a so-called process affinity binding to
specific cpus to reduce cache-faults, right?
this would require a soft-lock such as "rather take any cpu instead of
waiting fo r"my cpu" to become available, as "locking" would prevent other
processes from using the locked cpu when the main locked process is in
io-wait.
all-in-all this seems far more complicated than "locking" if it is to be
implemented without the waste of cpu cycles if the locked process is
idle...
so maybe it is easier without...
otoh, if you compare common i386 hardware to eg sun, where affinity
binding is common, you ll see that in i386 the memory is at the same
"distance" to every processor, while on sun, every processor has it s own
ram on the same sbus card. there it makes sense to bind the processor to
the app on it s "local" ram.
IMO this corresponds to hardware architecutre which is very uncommon on
i386, chrp ppc, alpha, s/390 and so on -- this might be important on sun
3000, 6000, 10000 servers as well as on some hp pa risc machines...
On Wed, 22 Mar 2000, NightRanger wrote:
> Is locking a process to a specific CPU under development for this kernel?
>
>
> Kelsey Hudson khudson@ctica.com
> Associate Software Engineer
> Compendium Technologies, Inc (619) 725-0771
>
> -Kicking the computer solves all the problems. Just try it!
>
>
> -
> 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/
>
-
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 : Sat Mar 25 2000 - 05:27:54 EST