Re: svn commit: r292074 - in head/sys/dev: nvd nvme

2016-03-11 Thread Jim Harris
On Fri, Mar 11, 2016 at 9:31 AM, Warner Losh wrote: > > > > And keep in mind the original description was this: > > Quote: > > Intel NVMe controllers have a slow path for I/Os that span > a 128KB stripe boundary but ZFS limits ashift, which is derived > from d_stripesize, to 13 (8KB) so we limit

Re: svn commit: r292074 - in head/sys/dev: nvd nvme

2016-03-11 Thread Warner Losh
On Fri, Mar 11, 2016 at 9:24 AM, Warner Losh wrote: > > > On Fri, Mar 11, 2016 at 9:15 AM, Alan Somers wrote: > >> Interesting. I didn't know about the alternate meaning of stripesize. I >> agree then that there's currently no way to tune ZFS to respect NVME's >> 128KB boundaries. One could s

Re: svn commit: r292074 - in head/sys/dev: nvd nvme

2016-03-11 Thread Warner Losh
On Fri, Mar 11, 2016 at 9:15 AM, Alan Somers wrote: > Interesting. I didn't know about the alternate meaning of stripesize. I > agree then that there's currently no way to tune ZFS to respect NVME's > 128KB boundaries. One could set zfs.vfs.vdev.aggregation_limit to 128KB, > but that would onl

Re: svn commit: r292074 - in head/sys/dev: nvd nvme

2016-03-11 Thread Alan Somers
Interesting. I didn't know about the alternate meaning of stripesize. I agree then that there's currently no way to tune ZFS to respect NVME's 128KB boundaries. One could set zfs.vfs.vdev.aggregation_limit to 128KB, but that would only halfway solve the problem, because allocations could be unal

Re: svn commit: r292074 - in head/sys/dev: nvd nvme

2016-03-11 Thread Alexander Motin
On 11.03.16 06:58, Alan Somers wrote: > Do they behave badly for writes that cross a 128KB boundary, but are > nonetheless aligned to 128KB boundaries? Then I don't understand how > this change (or mav's replacement) is supposed to help. The stripesize > is supposed to be the minimum write that t

Re: svn commit: r292074 - in head/sys/dev: nvd nvme

2016-03-10 Thread Alan Somers
Do they behave badly for writes that cross a 128KB boundary, but are nonetheless aligned to 128KB boundaries? Then I don't understand how this change (or mav's replacement) is supposed to help. The stripesize is supposed to be the minimum write that the device can accept without requiring a read-

Re: svn commit: r292074 - in head/sys/dev: nvd nvme

2016-03-10 Thread Warner Losh
Some Intel NVMe drives behave badly when the LBA range crosses a 128k boundary. Their performance is worse for those transactions than for ones that don't cross the 128k boundary. Warner On Thu, Mar 10, 2016 at 11:01 AM, Alan Somers wrote: > Are you saying that Intel NVMe controllers perform po

Re: svn commit: r292074 - in head/sys/dev: nvd nvme

2016-03-10 Thread Alan Somers
Are you saying that Intel NVMe controllers perform poorly for all I/Os that are less than 128KB, or just for I/Os of any size that cross a 128KB boundary? On Thu, Dec 10, 2015 at 7:06 PM, Steven Hartland wrote: > Author: smh > Date: Fri Dec 11 02:06:03 2015 > New Revision: 292074 > URL: https://

svn commit: r292074 - in head/sys/dev: nvd nvme

2015-12-10 Thread Steven Hartland
Author: smh Date: Fri Dec 11 02:06:03 2015 New Revision: 292074 URL: https://svnweb.freebsd.org/changeset/base/292074 Log: Limit stripesize reported from nvd(4) to 4K Intel NVMe controllers have a slow path for I/Os that span a 128KB stripe boundary but ZFS limits ashift, which is derived