From mboxrd@z Thu Jan 1 00:00:00 1970 From: mathieu.desnoyers@polymtl.ca (Mathieu Desnoyers) Date: Sat, 17 Jan 2009 12:15:56 -0500 Subject: [ltt-dev] [RFC PATCH] block: Fix bio merge induced high I/O latency In-Reply-To: References: <20090117004439.GA11492@Krystal> <20090117162657.GA31965@Krystal> Message-ID: <20090117171556.GA32572@Krystal> * Leon Woestenberg (leon.woestenberg at gmail.com) wrote: > Hello Mathieu et al, > > On Sat, Jan 17, 2009 at 5:26 PM, Mathieu Desnoyers > wrote: > > A long standing I/O regression (since 2.6.18, still there today) has hit > > Slashdot recently : > > http://bugzilla.kernel.org/show_bug.cgi?id=12309 > > Are you sure you are solving the *actual* problem? > > The bugzilla entry shows a bisect attempt that leads to a patch > involving negative clock jumps. > http://bugzilla.kernel.org/show_bug.cgi?id=12309#c29 > > with a corrected link to the bisect patch: > http://bugzilla.kernel.org/show_bug.cgi?id=12309#c30 > > Wouldn't a negative clock jump be very influential to the > (time-driven) I/O schedulers and be a more probable cause? > When a merge is done, the lowest timestamp between the existing request and the new request to merge is kept as a start_time value for the merged request we end up with. In this case, that would probably make that request stay on top of the queue even if unrelated interactive I/O requests come. I suspect that this negative clock jump could have hidden the problem by making the start time of the interactive request lower than the start time of the merged request. Mathieu > Regards, > -- > Leon > > p.s. Added Thomas to the CC list as his name is on the patch Signed-off-by list. -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68