[PATCH] Make fdescfs MPSAFE

[Ulf Lilleengen]

On tor, okt 18, 2007 at 10:47:05 +0200, Kris Kennaway wrote:
> Ulf Lilleengen wrote:
> >On tor, okt 18, 2007 at 09:33:40 +0200, Kris Kennaway wrote:
> >>Ulf Lilleengen wrote:
> >>>On tor, aug 16, 2007 at 12:05:26 +0200, Ulf Lilleengen wrote:
> >>>>Hi,
> >>>>
[...]
> >>>http://folk.ntnu.no/lulf/patches/freebsd/fdescfs/fdescfs_lock.diff
> >>This might be OK but you should be aware that rwlocks can be slower than 
> >>mutexes when there is a suitably mixed read/write workload.  We don't do 
> >>the same adaptive spinning for wlocks as for mutexes when they are held 
> >>by shared holders (since we don't track who they are so can't track 
> >>whether they're running), and it is possible for readers to starve 
> >>writers.
> >>
> >>If possible some benchmarks trying to find the worst case behaviour 
> >>would be useful.
> >Good point. I guess having a benchmark where one would open #hashentries
> >files, and then have #hashentries threads reading (accessing the files) and
> >one thread writing (closing perhaps) could produce the starvation?
> 
> Perhaps, give it a try :)
> 
I created the program found here:
http://folk.ntnu.no/lulf/dev/freebsd/fdescfs/benchmark.c

I compiled it with -lthr, and the hardware I've tested it on is a core duo,
as well as a dual-cpu p3 machine.

I tried opening X files, then having X "readers" doing a lookup on the
filedescriptors for those files in /dev/fd (Doing a lookup for a first time puts
it into the hash table (using wlock). Looking it up the second time, it will
just use rlock).

While these X readers was busy reading, tried to open a new file and doing
lookup on it (will try to insert and acquire wlock).

I tried with X = 1, 2, 4 and 16.

I was unable to produce the starvation with this. I'll try see if I can come up
with some other benchmark.

I assume it would be easier to reproduce it if I have CPUs I can run threads
on to assure I always hold it, but I don't.

Also, as a general way to observe behaviour in benchmarks, is there a way I
could force/check what CPU a thread is running on from userland?

-- 
Ulf Lilleengen