On Mon, Nov 28, 2016 at 11:11:18AM +0200, Avi Kivity wrote: > On 11/28/2016 11:00 AM, Christoph Hellwig wrote: > > On Mon, Nov 28, 2016 at 10:58:24AM +0200, Avi Kivity wrote: > > > What I guess is happening is that since the NVMe queue depth is so high, and > > > request the driver receives is sent immediately to the disk and there is > > > nothing to merge it to. That could indicate the absence of plugging, or > > > just a reluctance to merge TRIMs. > > That is exactly the case, and it's also an issue with online trim. > > I have work in progress block layer trim patches that always plug trims > > and have various TRIM merge improvements including support for ranged > > TRIMs. It needs a bit more work, but I hope I can post it later > > this week. > > Great, good to know. > > I still think it should also be fixed in the RAID layer. There's no reason > to break a single request in millions of smaller ones, then try to merge > them into one request back again. The queuing layer can merge when it's > given bad patterns from uncontrolled sources, not as an excuse to generate > bad patterns from within the kernel. I think the reason is you are using 4.1 kernel. upstream kernel does support request merge even for blk-mq. It didn't at some versions. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
