[OpenAFS-devel] better vcache/dcache locking

[Kevin Coffman]

I think you should expect to see the 26% improvement by fixing the 
locking so that the prefetch doesn't lock out the reader.  As I recall, 
the 40% number was a combination of bypassing the cache plus having the 
locking problem out of the way.  (Looking back, you're right, it is not 
very clear...)

And yes, we were only concerned with sequential reads.

I should be able to come up with diffs from our work if you think that 
would be helpful, but it sounds like you have a handle on the problem.

K.C.

> I've been trying to add better (OS-initiated) prefetch support
> to AFS, in particular on Solaris, and so far it seems to hurt
> more than it helps.  As far as I can tell, the problem is that
> the vcache locks double as dcache locks for dcache entries under
> that vcache.  This only allows one data fetch at a time for a
> given file.  The prefetch request causes the daemons to lock the
> vcache and prefetch pages ahead, while preventing the process from
> getting pages it needs now.
> 
> A possible solution seems to be adding rwlock's to dcache entries
> themselves.  They would protect the struct dcache as well as the
> underlying cache file contents.  It looks like there's already an
> afs_rwlock_t in struct dcache, although it's only used in a couple
> of places, and even there it's #ifdef'ed out.
> 
> The technical report Jim Rees referenced here a few weeks ago[1]
> also finds the same locking problem and points out they were able
> to achieve 26-40% speedup by avoiding it, presumably in the case
> of sequential reads.  (I'm not entirely certain what the difference
> between those two numbers in the report is.)
> 
> Since this is likely to be a fairly involved modification, I'd
> appreciate any thoughts or comments people might have about making
> such a change..
> 
> [1]  http://www.citi.umich.edu/techreports/reports/citi-tr-01-3.ps.gz
> 
> -- kolya
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>