From: Andrea Arcangeli <aarcange@redhat.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Mark Veltzer <mark.veltzer@gmail.com>,
linux-kernel@vger.kernel.org,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Andi Kleen <andi@firstfloor.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: get_user_pages question
Date: Mon, 30 Nov 2009 17:12:05 +0100 [thread overview]
Message-ID: <20091130161205.GE30235@random.random> (raw)
In-Reply-To: <20091130120145.GB21639@wotan.suse.de>
On Mon, Nov 30, 2009 at 01:01:45PM +0100, Nick Piggin wrote:
> If you can wean O_DIRECT off get_user_pages, you'd have most of the
> battle won. I don't think it's really possible though.
Agreed. Not just O_DIRECT, virtualization requires it too, the kvm
page fault calls get_user_pages, practically anything that uses mmu
notifier also uses get_user_pages. There are things you simply can't
do without it.
In general if the memory doesn't need to be persistently stored on
disk to survive task killage, there's not much point in using
pagecache MAP_SHARED on-disk, instead of anonymous memory, this is why
anonymous memory is backing malloc, and there's no reason why people
should be prevented to issue disk I/O in zero-copy with anonymous
memory (or tmpfs), if they know they access this data only once and
they want to manage the cache in some logical form rather than in
physical on-disk format (or if there are double physical caches more
efficient kept elsewhere, like in KVM guest case).
OTOH if you'd be using the I/O data in physical format in your
userland memory, then using pagecache by mmapping the file and
disabling O_DIRECT on the filesystem is surely preferred and more
efficient (if nothing else, because it also provides caching just in
case).
For drivers (Mark's case) it depends, but if you can avoid to use
get_user_pages without slowing down anything you should, that usually
makes code simpler... and it won't risk to suffer from these race
conditions either ;).
next prev parent reply other threads:[~2009-11-30 16:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-09 6:50 get_user_pages question Mark Veltzer
2009-11-09 9:31 ` Andi Kleen
2009-11-09 10:32 ` Hugh Dickins
2009-11-09 22:13 ` Mark Veltzer
2009-11-10 16:33 ` Hugh Dickins
2009-11-28 18:50 ` Andrea Arcangeli
2009-11-28 22:22 ` Mark Veltzer
2009-11-30 12:01 ` Nick Piggin
2009-11-30 16:12 ` Andrea Arcangeli [this message]
2009-11-30 11:54 ` Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2004-05-01 11:12 Eli Cohen
2004-05-01 11:32 ` Arjan van de Ven
2004-05-01 11:41 ` Eli Cohen
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=20091130161205.GE30235@random.random \
--to=aarcange@redhat.com \
--cc=andi@firstfloor.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.veltzer@gmail.com \
--cc=mtk.manpages@gmail.com \
--cc=npiggin@suse.de \
/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