Looks good to me.
Nick Piggin wrote:
> 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
> ==
Nick Piggin wrote:
> XFS's vmap batching simply defers a number (up to 64) of vunmaps, and keeps
> track of them in a list. To purge the batch, it just goes through the list and
> calls vunamp on each one. This is pretty poor: a global TLB flush is still
> performed on each vunmap, with the most ex
On Mon, 2008-08-04 at 05:13 +0100, Dave Airlie wrote:
> Well it can now, we just need to fix the X server :)
Yeah, I just discovered that today. Weird that the kernel was fixed
between the last time I looked and now though; NR_OPEN had been 1024 for
many years prior.
However, it's not just fixin
>
> Yes, with a 1-1 mapping between GPU objects and file objects. You can
> use the normal read/write/mmap API on them. The reason we aren't using
> fds now is just that the kernel cannot handle this many fds per process.
Well it can now, we just need to fix the X server :)
>
> I want to map t
Keith Packard wrote:
>
>
>> The other approach is to use one address space per device.
>>
>
> This would require constructing an entirely artificial linear space for
> my objects. You then have to track this per-device linear address for
> each object and pass that into the mmap call. And,
On Sun, 2008-08-03 at 08:07 +0100, Dave Airlie wrote:
> Isn't that also what you are trying to do with GEM though.. match GPU
> objects to the file interface.
Yes, with a 1-1 mapping between GPU objects and file objects. You can
use the normal read/write/mmap API on them. The reason we aren't us
On Sun, 2008-08-03 at 10:53 +0200, Thomas Hellström wrote:
> With the current GEM implementation, the address space is per buffer
> object, and if this were done
> correctly you'd duplicate the shmemfs filesystem to make a drmfs
> filesystem where you have complete control over creation and mmap
Keith Packard wrote:
>
>> and that's why TTM
>> needs to manage a fake linear address space for the drm fd.
>>
>
> Managing a fake linear address space just to match some existing
> arbitrary API requirements is insane. Creating the right interface for
> my UMA environment is my goal. I'm no
>
> Managing a fake linear address space just to match some existing
> arbitrary API requirements is insane. Creating the right interface for
> my UMA environment is my goal. I'm not sure precisely what that API
> should be, but at least this one is obviously wrong.
Isn't that also what you are t
