Re: [patch] SMP alternatives

[Zachary Amsden <zach@vmware.com>]

Jeff V. Merkey wrote:

> In 2-3 years we might actually see the hardware solution, maybee .... 
> I am skeptical Intel will move quickly on it. A software solution will 
> get out faster.



I'm not sure a hardware solution is even the right thing - consider a 
shared memory database process with a private heap.  You really want 
locks on the shared memory, and you really don't on the heap.

You need a way to type the lock semantics by memory region, and a 
working hardware solution can not perform as well as a careful software 
solution.  As was pointed out earlier, you can't use memory type 
attributes to infer lock semantics, you must assume them in the decoder 
or implement complex deadlock detection and recovery in silicon.

I would be willing to bet that library users know best.  Most cleanly 
written libraries already have wrapper functions that can be used to 
plug in needed libc functions like malloc, even file I/O.  Even if they 
don't, you can rewrap all of the imported functions.  Using this, you 
can isolate threaded libraries from single threaded applications, and 
make sure the performance critical libraries use non-threaded 
operations.  You can even afford to use a medium heavy hammer and switch 
from non-threaded to threaded dependent libraries every time you call a 
thread-using library function, because by assumption, the majority of 
performance critical code is going to be running single threaded.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/