On Thu, Oct 01, 2009 at 09:31:19AM -0700, Jeremy Fitzhardinge wrote:
> On 10/01/09 01:41, Jan Beulich wrote:
> >> Why, what's wrong with VM_IO? It's documented as being "Memory mapped
> >> I/O or similar". VM_PFNMAP is another option, but that seems more
> >> dubious. Are there places where VM_I
On Thu, Oct 01, 2009 at 09:41:39AM +0100, Jan Beulich wrote:
> >>> Jeremy Fitzhardinge 01.10.09 09:43 >>>
> >On 09/30/09 23:40, Jan Beulich wrote:
> >>> Hm, _PAGE_IOMAP is x86-specific. I guess that doesn't matter in this
> >>> case, but it would for other drivers. Previously _PAGE_IOMAP was set
On Saturday 28 March 2009 23:46:14 Peter Zijlstra wrote:
> On Sat, 2009-03-28 at 13:22 +0100, Peter Zijlstra wrote:
> > I'm not really trusting my brain today, but something like the below
> > should work I think.
> >
> > Nick, any thoughts?
> >
> > Not-Signed-off-by: Peter Zijlstra
> > ---
> > a
On Thu, Feb 19, 2009 at 09:49:40AM -0500, Kristian Høgsberg wrote:
>
> > Secondly, mmap_sem is not a recursive lock (very few kernel locks are,
> > and we generally frown upon recursive locking schemes), this means that
> > the fault handler still cannot function properly.
>
> I understand, but w
On Thu, Feb 19, 2009 at 10:19:05AM +0100, Peter Zijlstra wrote:
> On Wed, 2009-02-18 at 11:38 -0500, k...@bitplanet.net wrote:
> > From: Kristian Høgsberg
> >
> > A number of GEM operations (and legacy drm ones) want to copy data to
> > or from userspace while holding the struct_mutex lock. Howe
On Sunday 19 October 2008 06:31, Linus Torvalds wrote:
> On Sat, 18 Oct 2008, Keith Packard wrote:
> > The basic plan is to have four new functions (yes, I'm making up names
> > here):
> >
> > struct io_mapping *io_reserve_pci_resource(struct pci_dev *dev,
> >
On Saturday 18 October 2008 08:29, Dave Airlie wrote:
> Hi Linus,
>
> This is a new tree, I had a conflict with your latest tree due to some
> trivial cleanups you merged. I've added the fix for CVE-2008-3831 which is
> unembargoed.
>
> Please pull the 'drm-next' branch from
> ssh://master.kernel.o
On Friday 03 October 2008 15:17, Keith Packard wrote:
> On Thu, 2008-10-02 at 10:15 -0700, Jesse Barnes wrote:
> > At this point I think we should go ahead and include Eric's earlier
> > patchset into drm-next, and continue to refine the internals along the
> > lines of what you've posted here in t
On Wed, Sep 24, 2008 at 07:43:26PM -0700, Keith Packard wrote:
> On Thu, 2008-09-25 at 04:30 +0200, Nick Piggin wrote:
>
> > OK. I will have to add some facilities to allow mmaps that go back through
> > to tmpfs and be swappable... Thanks for the data point.
>
> It see
On Tue, Sep 23, 2008 at 08:50:29AM -0700, Keith Packard wrote:
> On Tue, 2008-09-23 at 11:10 +0200, Nick Piggin wrote:
> > I particularly don't like the idea of exposing these vfs objects to random
> > drivers because they're likely to get things wrong or become out of s
On Tue, Sep 23, 2008 at 12:21:26PM +0200, Thomas Hellström wrote:
> Nick,
> From my point of view, this is exactly what's needed, although there
> might be some different opinions among the
> DRM developers. A question:
>
> Sometimes it's desirable to indicate that a page / object is "cleaned",
On Wed, Sep 24, 2008 at 06:20:22PM -0700, Keith Packard wrote:
> On Thu, 2008-09-25 at 02:30 +0200, Nick Piggin wrote:
>
> > I guess so. A big problem of ioctls is just that they had been easier to
> > add so they got less thought and review ;) If your ioctls are stable,
E_MONITOR) += pagewalk.o
obj-$(CONFIG_BOUNCE) += bounce.o
Index: linux-2.6/mm/pageable_alloc.c
===
--- /dev/null
+++ linux-2.6/mm/pageable_alloc.c
@@ -0,0 +1,260 @@
+/*
+ * Simple pageable memory allocator
+ *
+ * Copyright (C) 2008 Nic
On Thu, Sep 11, 2008 at 06:16:21PM -0700, Jesse Barnes wrote:
> Here's an updated set of GTT mapping patches against Eric's drm-gem-merge
> branch from earlier today and DRM master for the libdrm bits. I fixed up a
> couple of bugs, but it looks like UXA/EXA still don't work against GEM even
>
the XFS changes to mainline
> or would you like us to?
>
> Nick Piggin wrote:
> >Thanks for taking a look. I'll send them over to -mm with patch 1,
> >then, for some testing.
> >
> >On Monday 04 August 2008 16:28, Lachlan McIlroy wrote:
> >>Looks good
Thanks for taking a look. I'll send them over to -mm with patch 1,
then, for some testing.
On Monday 04 August 2008 16:28, Lachlan McIlroy wrote:
> Looks good to me.
>
> Nick Piggin wrote:
> > Implement XFS's large buffer support with the new vmap APIs. See the vmap
&
Implement XFS's large buffer support with the new vmap APIs. See the vmap
rewrite patch for some numbers.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
===
--- linux-2.6.
prove vmap performance
and scalability directly in the previous and subsequent patch.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
===
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf
Hi all,
I plan to submit my vmap rewrite to -mm. Although I am not planning to submit
fsblock to be merged, I figure that at least XFS wants a fast, scalable vmap
in some configurations. Others may want as well (didn't look too hard, but
the DRM subsystem needs or will need much better performance
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/
Keith Whitwell wrote:
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate
kernel or
using a vendor kernel with backports. This model would work for
video drivers
aswell.
Sure, explain to me how I
21 matches
Mail list logo
