Date: Wed, 7 Dec 2016 21:08:17 +0200 From: Alexander Motin <mav@FreeBSD.org> To: freebsd-fs@FreeBSD.org Subject: Re: 11-STABLE vs 11.0-RELENG test Message-ID: <0b0a2d6c-59f2-aa0e-01ca-ca2613ccbe57@FreeBSD.org> In-Reply-To: <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07.12.2016 15:34, Alexander Motin wrote: > Closer look shown me the cause. This code sorts I/Os on time, offset > and memory address. But time on FreeBSD (to reduce overhead) returned > with 1ms resolution, so it does not provide reliable ordering. Offset > sorting used by this patch is broken by design, since io_offset field is > always zero there, since it is used only for physical I/Os, not for > logical. As result, I/Os are "sorted" on memory address, that in fact > means complete randomization of all allocations within one millisecond, > predictably killing read performance. > > Switching gethrtime() emulation from getnanouptime() to nanouptime() > fixes the read performance, resulting: > nanouptime() > write 702 > read w/ pref 845 > read w/o pref 272 > > It would be good to make offset sorting really work there rather then > just switching to high resolution time source, but that maybe quite > invasive. Will look more. PS: If somebody needs quick workaround, this loader tunable restores both read and write speed: vfs.zfs.zio.dva_throttle_enabled=0. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0b0a2d6c-59f2-aa0e-01ca-ca2613ccbe57>