Date: Sun, 24 Aug 2014 13:57:29 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: freebsd-hackers@freebsd.org Subject: atomic_load_acq_int in sequential_heuristic Message-ID: <20140824115729.GC2045@dft-labs.eu>
next in thread | raw e-mail | index | archive | help
Writer side is: fp->f_seqcount = (arg + bsize - 1) / bsize; do { new = old = fp->f_flag; new |= FRDAHEAD; } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); Reader side is: if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) return (fp->f_seqcount << IO_SEQSHIFT); We can easily get the following despite load_acq: CPU0 CPU1 load_acq fp->f_flag fp->f_seqcount = ... store_rel fp->f_flag read fp->f_seqcount So the barrier does not seem to serve any purpose. Given that this is only a hint and rarely changes it should be fine. So how about the following: diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index f1d19ac..2e056de 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -438,7 +438,7 @@ static int sequential_heuristic(struct uio *uio, struct file *fp) { - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) + if (fp->f_flag & FRDAHEAD) return (fp->f_seqcount << IO_SEQSHIFT); /* I make no claims about any performance difference in this one. This is only a cleanup. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140824115729.GC2045>