Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
First, the locks are not the issue. The only possible effect of a lock is to make the other CPUs spin in place. It there are no other CPUs, then the lock owner is by definition not restricted and no CPUs exist which could be restricted. There is probably a very tiny overhead introduced by setting, resetting, and checking the lock status, but I doubt this could even be measured. Of greater concern would be that certain optimizations which are allowed under a uniprocessor system would be disallowed under a multiprocessor system. Most of these would be actions which make use of some nonshared resource, such as the cache or a video accelerator. This sort of thing would be hard to measure, although it might be large, because the complexity of interactions could make only certain rarely encountered pathological situations interesting. For example, you might find that your system bottleneck suddenly becomes the scatter-gather algorithm in your SCSI controller, which is obviously not what you want to test. I assume you are aware that there are radical changes to the SMP locking scheme between kernels 2.2 and 2.4, especially with regard to granularity. -- Mike On 2000-12-05 at 05:12 -0000, Ming Chow wrote: > I am currently doing some investigation on SMP-style kernel locking (on > single processor machines). I have compiled an SMP-enabled kernel on a > single processor machine. I am trying to see if there are any performance > differences between SMP kernel locking and a non-SMP kernel locking (i.e. if > anything slows down). If there are, what can I do in the kernel source code > to prove or show the performance differences? Any help would be greatly > appreciated! Thanks! - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |