[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <46D67057.9030905@yahoo.com.au>
Date: Thu, 30 Aug 2007 17:23:03 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Peter Zijlstra <peterz@...radead.org>
CC: Dave Airlie <airlied@...il.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
dri-devel <dri-devel@...ts.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Memory Management <linux-mm@...ck.org>
Subject: Re: uncached page allocator
Peter Zijlstra wrote:
> On Tue, 2007-08-21 at 16:05 +1000, Dave Airlie wrote:
>
>
>>So you can see why some sort of uncached+writecombined page cache
>>would be useful, I could just allocate a bunch of pages at startup as
>>uncached+writecombined, and allocate pixmaps from them and when I
>>bind/free the pixmap I don't need the flush at all, now I'd really
>>like this to be part of the VM so that under memory pressure it can
>>just take the pages I've got in my cache back and after flushing turn
>>them back into cached pages, the other option is for the DRM to do
>>this on its own and penalise the whole system.
>
>
> Can't you make these pages part of the regular VM by sticking them all
> into an address_space.
>
> And for this reclaim behaviour you'd only need to set PG_private and
> have a_ops->releasepage() dtrt.
I'd just suggest Dave just registers a shrinker to start with.
You really want to be able to batch TLB flushes as well, which
->releasepage may not be so good at (you could add more machinery
behind the releasepage to build batches and so on, but anyway, a
shrinker might be the quickest way to get something working).
--
SUSE Labs, Novell Inc.
-
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