On 2016/11/28 下午5:11, 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. Personally I agree with your opinion. We can improve both in block layer and md code. Coly -- 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
