On Fri, Apr 12, 2019 at 01:17:40PM +0300, Nikolay Borisov wrote: > > > On 10.04.19 г. 22:56 ч., Josef Bacik wrote: > > When diagnosing a slowdown of generic/224 I noticed we were wasting a > > lot of time in shrink_delalloc() despite all writes being O_DIRECT > > writes. O_DIRECT writes still have outstanding extents, but obviously > > cannot be directly flushed, instead we need to wait on their > > corresponding ordered extent. Track the outstanding odirect write bytes > > and if this amount is higher than the delalloc bytes in the system go > > ahead and force us to wait on the ordered extents. > > This is way too sparse. I've been running generic/224 to try and > reproduce your slowdown. So far I can confirm that this test exhibits > drastic swings in performance - I've seen it complete from 30s up to > 300s. I've also been taking an offcputime[0] measurements in the case > where high completion times were observed but so far I haven't really > seen shrink_delalloc standing out. >
It's not, I shouldn't have said "wasting time" I should have said most calls to shrink_delalloc did nothing. The rest is self explanatory. shrink_delalloc() keys off of fs_info->delalloc_bytes, which is 0 if you have nothing but O_DIRECT. Thus we need a mechanism for seeing that there's O_DIRECT in flight and we would benefit from waiting on ordered extents. The slowdown is addressed in patch 2, this patch just makes it so shrink_delalloc() actually does something if we are O_DIRECT. Thanks, Josef
