[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20091130161205.GE30235@random.random>
Date: Mon, 30 Nov 2009 17:12:05 +0100
From: Andrea Arcangeli <aarcange@...hat.com>
To: Nick Piggin <npiggin@...e.de>
Cc: Mark Veltzer <mark.veltzer@...il.com>,
linux-kernel@...r.kernel.org,
Hugh Dickins <hugh.dickins@...cali.co.uk>,
Andi Kleen <andi@...stfloor.org>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: get_user_pages question
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 ;).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists