linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Zdenek Kabelac <zkabelac@redhat.com>,
	Lukas Czerner <lczerner@redhat.com>,
	Miklos Szeredi <miklos@szeredi.hu>, Borislav Petkov <bp@suse.de>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH mmotm v2] tmpfs: do not allocate pages on read
Date: Tue, 8 Mar 2022 13:46:15 -0800 (PST)	[thread overview]
Message-ID: <9798e3b-1c2a-6c47-decc-7d4148de5114@google.com> (raw)
In-Reply-To: <20220308172734.GC1479066@magnolia>

On Tue, 8 Mar 2022, Darrick J. Wong wrote:
> 
> I've long wondered (for my own nefarious purposes) why tmpfs files
> didn't just grab the zero page,

(tmpfs files have been using the zero page for reads for many years:
it was just this odd internal "could it be for a stacking filesystem?"
case, which /dev/loop also fell into, which was doing allocation on read.

I wonder what your nefarious purposes are ;) Maybe related to pages
faulted into an mmap: those pages tmpfs has always allocated for, then
they're freed up later by page reclaim if still undirtied. We may change
that in future, and use the zero page even there: there are advantages
of course, but some care and code needed - never been a priority.)

> so:
> 
> Acked-by: Darrick J. Wong <djwong@kernel.org>

Thanks,
Hugh

      reply	other threads:[~2022-03-08 21:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-05  5:09 [PATCH mmotm] tmpfs: do not allocate pages on read Hugh Dickins
2022-03-06  9:27 ` Christoph Hellwig
2022-03-06 22:56   ` Hugh Dickins
2022-03-06 22:59   ` [PATCH mmotm v2] " Hugh Dickins
2022-03-07  6:44     ` Christoph Hellwig
2022-03-08 17:27       ` Darrick J. Wong
2022-03-08 21:46         ` Hugh Dickins [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9798e3b-1c2a-6c47-decc-7d4148de5114@google.com \
    --to=hughd@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=lczerner@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=mpatocka@redhat.com \
    --cc=zkabelac@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).