Re: Re: [PATCH v14] mm: don't set readahead flag on a folio when lookahead_size > nr_to_read

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

 



On Wed, Oct 16, 2024 at 03:35:27PM +0530, Pankaj Raghav (Samsung) wrote:
> > > - The current calculation for `mark` with mapping_min_order > 0 gives
> > >   incorrect results when lookahead_size > nr_to_read due to rounding
> > >   up operation.
> > > 
> > > Explicitly initialize `mark` to be ULONG_MAX and only calculate it
> > > when lookahead_size is within the readahead window.
> > 
> > You haven't really spelled out the consequences of this properly.
> > Perhaps a worked example would help.
> 
> Got it. I saw this while running generic/476 on XFS with 64k block size.
> 
> Let's assume the following values:
> index = 128
> nr_to_read = 16
> lookahead_size = 28
> mapping_min_order = 4 (16 pages)
> 
> The lookahead_size is actually lying outside the current readahead
> window. The calculation without this patch will result in incorrect mark
> as follows:
> 
> ra_folio_index = round_up(128 + 16 - 28, 16) = 128;
> mark = 128 - 128 = 0;
> 
> So we will be marking the folio on 0th index with RA flag, even though
> we shouldn't have. Does that make sense?

But we don't go back and find the folio for index 0.  We only consider
the folios we're actually reading for marking.  So if 'mark' lies
outside the readahead window, we simply won't mark any of them.  So I
don't think your patch changes anything.  Or did I miss something?





[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