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.