On Wed, Oct 30, 2024 at 01:26:38PM -0700, Bart Van Assche wrote: > On 10/30/24 1:11 PM, Keith Busch wrote: > > On Wed, Oct 30, 2024 at 05:46:58AM +0100, Christoph Hellwig wrote: > > > On Tue, Oct 29, 2024 at 10:25:11AM -0700, Bart Van Assche wrote: > > > > > +} > > > > > > > > bitmap_copy() is not atomic. Shouldn't the bitmap_copy() call be > > > > serialized against the code that tests bits in bdev->write_hint_mask? > > > > > > It needs something. I actually pointed that out last round, but forgot > > > about it again this time :) > > > > I disagree. Whether we serialize it or not, writes in flight will either > > think it can write or it won't. There's no point adding any overhead to > > the IO path for this as you can't stop ending up with inflight writes > > using the tag you're trying to turn off. > > Shouldn't the request queue be frozen while this write_hint_mask bitmap > is modified, just like the request queue is frozen while queue limits > are updated? This change wouldn't add any additional overhead to the I/O > path. The partitions don't have a queue. If we need to freeze, then changing one partition's available hints harms IO to other partitions. Also, block direct IO creates the bio before it freezes. Freezing would only get writes using the hint you're trying to disable queue up after all the checks have been done, so you still can't stop making inflight writes with freeze. But if by "not atomic", if you're just saying we need a barrier on the bitmap_copy, like smp_mb__after_atomic(), then yeah, I see that's probably appropriate here.
