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
