Date: Wed, 20 Aug 2014 11:11:47 -0400 From: John Baldwin <jhb@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Robert Watson <rwatson@freebsd.org>, Mateusz Guzik <mjguzik@gmail.com>, Konstantin Belousov <kib@freebsd.org>, Johan Schuijt <johan@transip.nl>, freebsd-arch@freebsd.org Subject: Re: [PATCH 0/2] plug capability races Message-ID: <201408201111.47601.jhb@freebsd.org> In-Reply-To: <20140816102840.V1007@besplex.bde.org> References: <1408064112-573-1-git-send-email-mjguzik@gmail.com> <201408151031.45967.jhb@freebsd.org> <20140816102840.V1007@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 15, 2014 9:34:59 pm Bruce Evans wrote: > On Fri, 15 Aug 2014, John Baldwin wrote: > > > One thing I would like to see is for the timecounter code to be adapted to use > > the seq API instead of doing it by hand (the timecounter code is also missing > > barriers due to doing it by hand). > > Locking in the timecounter code is poor (1), but I fear a general mechanism > would be slower. Also, the timecounter code now extends into userland, > so purely kernel locking cannot work for it. The userland part is > more careful about locking than the kernel. It has memory barriers and > other pessimizations which were intentionally left out of the kernel > locking for timecounters. If these barriers are actually necessary, then > they give the silly situation that there are less races for userland > timecounting than kernel timecounting provided userland mostly does > direct accesses instead of syscalls and kernel uses of timecounters are > are infrequent enough to not race often with the userland accesses. Yes, the userland code is more correct here. The barriers are indeed missing in the kernel part, and adding them should give something equivalant to a correctly working seq API as it is doing the same thing. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408201111.47601.jhb>