RELENG_10 performance regression (was Re: 35-40% performance drop releng9 vs releng10 openvpn

[Konstantin Belousov]

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.