Re: [PATCH v6 09/19] mm: Add page_cache_readahead_limit

John Hubbard
2020-02-19T02:47:06Z

On 2/18/20 6:23 PM, Matthew Wilcox wrote:
> On Tue, Feb 18, 2020 at 05:32:31PM -0800, John Hubbard wrote:
>>> + page_cache_readahead_limit(inode->i_mapping, NULL,
>>> + index, LONG_MAX, num_ra_pages, 0);
>>
>>
>> LONG_MAX seems bold at first, but then again I can't think of anything smaller
>> that makes any sense, and the previous code didn't have a limit either...OK.
>
> Probably worth looking at Dave's review of this and what we've just
> negotiated on the other subthread ... LONG_MAX is gone.

Great. OK, I see where it's going there.

>
>> I also wondered about the NULL file parameter, and wonder if we're stripping out
>> information that is needed for authentication, given that that's what the newly
>> written kerneldoc says the "file" arg is for. But it seems that if we're this
>> deep in the fs code's read routines, file system authentication has long since
>> been addressed.
>
> The authentication is for network filesystems. Local filesystems
> generally don't use the 'file' parameter, and since we're going to be
> calling back into the filesystem's own readahead routine, we know it's
> not needed.
>
>> Any actually I don't yet (still working through the patches) see any authentication,
>> so maybe that parameter will turn out to be unnecessary.
>>
>> Anyway, It's nice to see this factored out into a single routine.
>
> I'm kind of thinking about pushing the rac in the other direction too,
> so page_cache_readahead_unlimited(rac, nr_to_read, lookahead_size).
>
>>> +/**
>>> + * page_cache_readahead_limit - Start readahead beyond a file's i_size.
>>
>>
>> Maybe:
>>
>> "Start readahead to a caller-specified end point" ?
>>
>> (It's only *potentially* beyond files's i_size.)
>
> My current tree has:
> * page_cache_readahead_exceed - Start unchecked readahead.

Sounds good.

>
>
>>> + * @mapping: File address space.
>>> + * @file: This instance of the open file; used for authentication.
>>> + * @offset: First page index to read.
>>> + * @end_index: The maximum page index to read.
>>> + * @nr_to_read: The number of pages to read.
>>
>>
>> How about:
>>
>> "The number of pages to read, as long as end_index is not exceeded."
>
> API change makes this irrelevant ;-)
>
>>> + * @lookahead_size: Where to start the next readahead.
>>
>> Pre-existing, but...it's hard to understand how a size is "where to start".
>> Should we rename this arg?
>
> It should probably be lookahead_count.
>
>>> + *
>>> + * This function is for filesystems to call when they want to start
>>> + * readahead potentially beyond a file's stated i_size. If you want
>>> + * to start readahead on a normal file, you probably want to call
>>> + * page_cache_async_readahead() or page_cache_sync_readahead() instead.
>>> + *
>>> + * Context: File is referenced by caller. Mutexes may be held by caller.
>>> + * May sleep, but will not reenter filesystem to reclaim memory.
>>
>> In fact, can we say "must not reenter filesystem"?
>
> I think it depends which side of the API you're looking at which wording
> you prefer ;-)
>
>

Yes. We should try to write these so that it's clear which way we're looking:
in or out.

thanks,
--
John Hubbard
NVIDIA