On 21.10.21 14:03, Kent Overstreet wrote: > On Thu, Oct 21, 2021 at 09:21:17AM +0200, David Hildenbrand wrote: >> On 21.10.21 08:51, Christoph Hellwig wrote: >>> FYI, with my block and direct I/O developer hat on I really, really >>> want to have the folio for both file and anon pages. Because to make >>> the get_user_pages path a _lot_ more efficient it should store folios. >>> And to make that work I need them to work for file and anon pages >>> because for get_user_pages and related code they are treated exactly >>> the same. > > ++ > >> Thanks, I can understand that. And IMHO that would be even possible with >> split types; the function prototype will simply have to look a little >> more fancy instead of replacing "struct page" by "struct folio". :) > > Possible yes, but might it be a little premature to split them? Personally, I think it's the right thing to do to introduce something limited like "struct filemap" (again, bad name, i.e., folio restricted to the filemap API) first and avoid introducing a generic folio thingy. So I'd even consider going with folios all the way premature. But I assume what to consider premature and what not depends on the point of view already. And maybe that's the biggest point where we all disagree. Anyhow, what I don't quite understand is the following: as the first important goal, we want to improve the filemap API; that's a noble goal and I highly appreciate Willy's work. To improve the API, there is absolutely no need introduce generic folio. Yet we argue about whether generic folio vs. filemap specific folio seems to be the right thing to do as a first step. My opinion after all the discussions: use a dedicate type with a clear name to solve the immediate filemap API issue. Leave the remainder alone for now. Less code to touch, less subsystems to involve (well, still a lot), less people to upset, less discussions to have, faster review, faster upstream, faster progress. A small but reasonable step. But maybe I'm just living in a dream world :) -- Thanks, David / dhildenb
