Date: Mon, 22 Oct 2007 18:00:41 +0200 From: Ulf Lilleengen <lulf@stud.ntnu.no> To: Kris Kennaway <kris@FreeBSD.org> Cc: freebsd-fs@freebsd.org Subject: Re: [PATCH] Make fdescfs MPSAFE Message-ID: <20071022160041.GA12710@stud.ntnu.no> In-Reply-To: <47171D89.7030906@FreeBSD.org> References: <20070816100526.GA31897@stud.ntnu.no> <20071017220948.GA4279@stud.ntnu.no> <47170C54.6050502@FreeBSD.org> <20071018083448.GA1079@stud.ntnu.no> <47171D89.7030906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071022160041.GA12710>