Re: [RFC 2/2] iomap: Support subpage size dirty tracking to improve write performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22/11/04 12:27AM, Christoph Hellwig wrote:
> On Wed, Nov 02, 2022 at 10:35:38AM -0700, Darrick J. Wong wrote:
> > Just so long as nobody imports that nonfeature of the bufferhead code
> > where dirtying an already dirty bufferhead skips marking the folio dirty
> > and writepage failures also fail to redirty the page.  That bit us hard
> > recently and I strongly prefer not to repeat that.
> 
> Yes, that absolutely needs to be avoided.

Sure, I am trying to discuss & investigate more in the same lines to avoid
the coherency problems (if any) in the other thread. 

i.e. to understand the rules between keeping the iomap->state[] dirty bitmap in 
sync with folio dirtiness (in folio_mark_dirty() / folio_cancel_dirty())
When are those required / what "external operations" could require 
folio_mark_dirty() to have a call to iomap_set_range_dirty() to dirty the
iop->state[] bitmaps.
Similary for marking it clean e.g. in folio_cancel_dirty().

In parallel I am looking into, to have a quick test case which could help me
replicate such scenario.

> 
> > > We can always optimize by having a bit for the fairly common all dirty
> > > case and only track and look at the array if that is no the case.
> > 
> > Yes, it would help to make the ranges in the bit array better defined
> > than the semi-opencoded logic there is now.  (I'm whining specifically
> > about the test_bit calls sprinkled around).
> 
> That is an absolutely requirement.  It was so obviosu to me that I
> didn't bother to restate it after two others already pointed it out :)

Yes. I will make those changes once rest of the things are sorted. 

> 
> > Once that's done it
> > shouldn't be hard to add one more bit for the all-dirty state.  Though
> > I'd want to see the numbers to prove that it saves us time anywhere.
> 
> We might be able to just use PG_private_2 in the page for now, but
> maybe just adding a flags field to the iomap_page might be a better
> idea, as the pageflags tend to have strange entanglements.

Sure, thanks for the suggestions. 

-ritesh



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux