Date: Sat, 21 Mar 2015 02:15:59 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: d@delphij.net Cc: John-Mark Gurney <jmg@funkthat.com>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: RELENG_10 performance regression (was Re: 35-40% performance drop releng9 vs releng10 openvpn Message-ID: <20150321001559.GB2379@kib.kiev.ua> In-Reply-To: <550CB306.7030405@delphij.net> References: <5506250A.2000506@sentex.net> <20150316132055.GQ32288@funkthat.com> <5509D6C6.4050204@sentex.net> <20150318211457.GL51048@funkthat.com> <550B6950.8060806@sentex.net> <550C5AAF.9060502@sentex.net> <550C8AEE.4090408@sentex.net> <550CB306.7030405@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 20, 2015 at 04:53:42PM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 03/20/15 14:02, Mike Tancsa wrote: > > OK, I think I found where the RELENG_10 performance loss happened. > > It seems > > https://lists.freebsd.org/pipermail/svn-src-stable-10/2015-March/004778.html > > > > is the issue. > > > > Testing with a kernel from r279796 I get 76-77Mb of throughput. > > With r279848 it drops to about 60Mb > > Hrm, looking at 'diffgraph.svg', it suggest that writing through devfs > have incurred a tax on writev(2), which is basically this codepath, if > my reading is correct, in sys/fs/devfs/devfs.c: > > 1676 static int > 1677 devfs_write_f(struct file *fp, struct uio *uio, struct ucred > *cred, > 1678 int flags, struct thread *td) > 1679 { > ... > 1703 if (uio->uio_resid != resid || (error == 0 && resid != > 0)) { > 1704 vfs_timestamp(&dev->si_ctime); > 1705 dev->si_mtime = dev->si_ctime; > 1706 } > > Further looking at the code, in devfs vfs_timestamp() is also called > when reading from a device node. When the setting was 0, the code > would return time_second directly instead of attempting to read the > timestamp. > > For the purpose of devfs, does it make sense to bump timestamps like > normal filesystems for each read/write operation? Looks like Mac OS X > will bump timestamps for each operation but Debian don't. First question is, what timecounter hardware is used. I would accept some slowdown from hardware like HPET, but it is indeed surprising if caused by TSC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150321001559.GB2379>