lkml.org 
[lkml]   [2021]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] Memory folios for v5.15
    On Tue, Aug 24, 2021 at 04:54:27PM +0100, David Howells wrote:
    > One question does spring to mind, though: do filesystems even need to know
    > about hardware pages at all? They need to be able to access source data or a
    > destination buffer, but that can be stitched together from disparate chunks
    > that have nothing to do with pages (eg. iov_iter); they need access to the
    > pagecache, and may need somewhere to cache pieces of information, and they
    > need to be able to pass chunks of pagecache, data or bufferage to crypto
    > (scatterlists) and I/O routines (bio, skbuff) - but can we hide "paginess"
    > from filesystems?
    >
    > The main point where this matters, at the moment, is, I think, mmap - but
    > could more of that be handled transparently by the VM?

    It really depends on the filesystem. I just audited adfs, for example,
    and there is literally nothing in there that cares about struct page.
    It passes its arguments from ->readpage and ->writepage to
    block_*_full_page(); it uses cont_write_begin() for its ->write_begin;
    and it uses __set_page_dirty_buffers for its ->set_page_dirty.

    Then there are filesystems like UFS which use struct page extensively in
    its directory handling. And NFS which uses struct page throughout.
    Partly there's just better infrastructure for block-based filesystems
    (which you're fixing) and partly NFS is trying to perform better than
    a filesystem which exists for compatibility with a long-dead OS.

    > > Because, as you say, head pages are the norm. And "folio" may be a
    > > clever term, but it's not very natural. Certainly not at all as
    > > intuitive or common as "page" as a name in the industry.
    >
    > That's mostly because no one uses the term... yet, and that it's not commonly
    > used. I've got used to it in building on top of Willy's patches and have no
    > problem with it - apart from the fact that I would expect something more like
    > a plural or a collective noun ("sheaf" or "ream" maybe?) - but at least the
    > name is similar in length to "page".
    >
    > And it's handy for grepping ;-)

    If the only thing standing between this patch and the merge is
    s/folio/ream/g, I will do that. All three options are equally greppable
    (except for 'ream' as a substring of dream, stream, preamble, scream,
    whereami, and typos for remain).

    \
     
     \ /
      Last update: 2021-08-24 20:04    [W:6.112 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site