Date: Wed, 14 Feb 2018 18:18:50 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 209571] NVMe performing poorly. TRIM requests stall I/O activity Message-ID: <bug-209571-3630-hfOSYli3l9@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209571-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-209571-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209571 Conrad Meyer <cem@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cem@freebsd.org Summary|ZFS and NVMe performing |NVMe performing poorly. |poorly. TRIM requests stall |TRIM requests stall I/O |I/O activity |activity --- Comment #6 from Conrad Meyer <cem@freebsd.org> --- I see the exact same problem with TRIM, Samsung 960 EVO, and UFS. Part of the problem is consumer controller (960 EVO) doing a bad job with TRIM. Part of the problem is nvd does not coalesces TRIMs. Part of the problem is cam_iosched separates out and prioritizes TRIM over all other IO; see cam_iosched_next_bio(). (Separating out is useful for coalescing, but we don't actually coalesce yet.) I observed iostat showing non-zero queue depths and long IO latencies with TRIM enabled (960 EVO). With TRIM disabled, qdepth was at most ever 1 and IO latency fell drastically under the same workload. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209571-3630-hfOSYli3l9>