On Sun, Mar 13, 2005 at 02:47:06PM -0500, Kyle Moffett wrote: > On Mar 13, 2005, at 14:32, Tom Keiser wrote: > >ok. I've been operating under the assumption that implementing a > >purely userspace gettimeofday would be too costly, but apparently that > >assumption is false. If you're only storing seconds since the epoch, > >your value is atomic, so you don't need sanity checking to prevent > >time apparently going backwards. > > Agreed (Although that's somewhat architecture and compiler dependent). > > >I agree that if you're going to store usecs too, then you need the > >read barriers. When I said we could coalesce ops and reduce the > >number of barriers, I was thinking about a technique similar to RCU > >that Herlihy discussed back in the late 80's > > Interesting. In any case, it's very efficient to do both time() and > gettimeofday() in userspace without using much CPU time. > > >>My goal for this implementation > > Hrm, I appear to have inadvertently deleted a paragraph or two from > my response in that email, oops!
Have you tried implementing this in the fileserver yet, so we've got some real numbers to look at? I'm kinda stumped as to why I can get 50MB/sec via NFS to the /vicepa partition, but through AFS, I'm only getting about 5. (I've tried both openafs and the 2.6.11 in-kernel AFS). This is a single 4.2GB file I'm testing with, FYI. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
