[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070107183946.GB8158@infradead.org>
Date: Sun, 7 Jan 2007 18:39:46 +0000
From: Christoph Hellwig <hch@...radead.org>
To: Christoph Hellwig <hch@...radead.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Ingo Molnar <mingo@...e.hu>, Zachary Amsden <zach@...are.com>,
Jeremy Fitzhardinge <jeremy@...source.com>,
Chris Wright <chrisw@...s-sol.org>,
Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
Arjan van de Ven <arjan@...radead.org>,
Adrian Bunk <bunk@...sta.de>, airlied@...ux.ie
Subject: Re: [patch] paravirt: isolate module ops
On Sat, Jan 06, 2007 at 07:31:52PM +0000, Christoph Hellwig wrote:
> On Sun, Jan 07, 2007 at 03:18:45AM +1100, Rusty Russell wrote:
> > PS. drm_memory.h has a "drm_follow_page": this forces us to uninline
> > various page tables ops. Can this use follow_page() somehow, or do we
> > need an "__follow_page" export for this case?
>
> Not if avoidable. And it seems avoidable as drm really should be using
> vmalloc_to_page. Untested patch below:
Even better we can actualy avid most of the page table walks completely.
First there is a number of places that can never have the vmalloc case
an may use ioremap/iounmap directly. Secondly drm_core_ioremap/
drm_core_ioremapfree already have the right drm_map to check wich kind
of mapping we have - we just need to use it instead of discarding that
information! The only leaves direct drm_ioremapfree in i810_dma.c and
i830_dma.c which I don't quite manage to follow. Maybe Dave has an
idea how to get rid of those aswell.
View attachment "drm-avoid-drm_ioremap" of type "text/plain" (1987 bytes)
View attachment "simplify-drm_core_ioremap" of type "text/plain" (2817 bytes)
Powered by blists - more mailing lists