What's small?

This is not a safe assumption; consider the case of a distributed cluster which supported migration. High communications latencies between processors are destructive.

Equally, on low latency communications links, such as in a 4-way Xeon system, the amount of interprocessor contention on cache line invalidation is significant.

If there isn't such conetntion, why lock it?

If there is such contention, why take the invalidation hit for all processors, instead of (on average) 1.5?

From a research perspective, consider the case of goal-based computing, goal-based computing where the participants have incomplete information, and cooperative robotics.

These are fields of research where your simplification will make use of BSD impossible.

A multithreaded file system architecture could be used to implement a concurrent "team" type program, which transfered data from one region in a contention domain to another. If that were implemented using your approach, there would by lockstep read/write/read/write, rather than concurrent operation with a single latency (e.g. read/write+read/write+read/.../write).

This is the moral equivalent of a sliding window for data copies on contention domains, involving two processors.

One of the basic flaws of SVR4 based Dynix for a very long time (and perhaps still; I haven't been inside a Sequent box for 2 years now) was that the FSA was not multithreaded.

If you want a more prosaic example, take any web server you currently operate, and replace the GIF images with CGI's that invoke the "team" program to stream the data out to the requester, instead of delivering the image directly.

Note the almost 170% improvement in download time for the pages (this is the same reason that "sendfile" is a stupid idea, given that it can never achieve this improvement becuase it can never achieve this concurrency, even if you could send all the data in the UNIX disk format).

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message