Using Server Stamps



next up previous
Next: Eager scheme Up: Optimizations Previous: Reducing Switch Stalls

Using Server Stamps

 

The current system uses both client-server stamps and server stamps in multistamps; it replaces client-server stamps with server stamps when the number of stamps for a server exceeds a bound (10 in our system). We also ran experiments where only server stamps were used. We found that the two systems ran identically when multistamp size (in number of entries) was held constant. However, multistamps containing only server stamps are smaller than those containing client-server stamps, and therefore we can get the same low stall rates with less space and smaller messages using server stamps.

We believe, however, that our workloads are biased towards server stamps since all clients that share a server also share pages at that server, so that page modifications are likely to cause invalidations for many clients. Therefore, there is not much information loss when client-server stamps are replaced by server stamps. Instead, consider two clients C and D that share pages from server S and also both use R but do not share any pages at R. If client C fetches a page from S that was modified in a multi-server transaction by client D, C can stall unnecessarily due to invalidations generated by D for some other client. Depending on the sharing patterns in the system, the client-server stamp system will dynamically replace some client-server stamps with a server stamp. Thus, if the above sharing pattern occurs, the client-server stamp system may be able to handle it better than the server-stamp system. This pattern may be quite likely in practice, and therefore client-server stamps seem like a good idea since they are not very expensive.


Atul Adya
Wed Jun 25 15:09:14 EDT 1997