From: Hugh Dickins <hugh@veritas.com>
To: "Eugene V. Lyubimkin" <jackyf.devel@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Peter Zijlstra <peterz@infradead.org>,
Chris Friesen <cfriesen@nortel.com>,
Rik van Riel <riel@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>
Subject: Re: mmap: is default non-populating behavior stable?
Date: Wed, 5 Nov 2008 23:31:35 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.64.0811052307460.5496@blonde.site> (raw)
In-Reply-To: <4911DCEF.80904@gmail.com>
On Wed, 5 Nov 2008, Eugene V. Lyubimkin wrote:
> Hugh Dickins wrote:
>
> >>From time to time we toy with prefaulting adjacent pages when a fault
> > occurs (though IIRC tests have proved disappointing in the past): we'd
> > like to keep that option open, but it would go against your guidelines
> > above to some extent.
> It depends how is "adjacent" would count :) If several pages, probably not.
> If millions or similar, that would be a problem.
That's fine, you'll be safe: you can be sure that it would never be
in the kernel's interest to prefault more than "several" extra pages.
Well, bearing in mind that famous "640K enough for all" remark, let's
not say "never"; but it won't prefault millions until memory is so abundant
and I/O so fast that you'd be happy with it prefaulting millions yourself.
> It's very convenient to use such
> "open+truncate+mmap+write/read" behavior to make self-growing-on-demand cache
> in memory with disk as back-end without remaps.
Yes. Though one thing to beware of is running out of disk space:
whereas a write system call should be good at reporting -ENOSPC,
the filesystem may not be able to handle running out of disk space
when writing back dirty mmaped pages - it may quietly lose the data.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2008-11-05 23:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <490F73CD.4010705@gmail.com>
2008-11-03 22:41 ` Peter Zijlstra
2008-11-03 22:49 ` Rik van Riel
2008-11-04 15:56 ` Chris Friesen
2008-11-04 16:07 ` Peter Zijlstra
2008-11-04 16:28 ` Alan Cox
2008-11-04 16:51 ` Eugene V. Lyubimkin
2008-11-05 16:42 ` Hugh Dickins
2008-11-05 16:54 ` Alan Cox
2008-11-05 17:50 ` Eugene V. Lyubimkin
2008-11-05 23:31 ` 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=Pine.LNX.4.64.0811052307460.5496@blonde.site \
--to=hugh@veritas.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cfriesen@nortel.com \
--cc=jackyf.devel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=riel@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