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
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
http://bugs.freedesktop.org/show_bug.cgi?id=16982
Summary: Problems with DRM on G33 chipset
Product: DRI
Version: DRI CVS
Platform: x86-64 (AMD64)
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: medium
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
rewrite patch for some numbers.
On Fri, Aug 1, 2008 at 6:27 PM, Dave Airlie [EMAIL PROTECTED] wrote:
Personally, I only use the existing DRM repo on old kernels because that's
how
it's structured. It's actually more work for me to download build a
recent
kernel, then update build the DRM drivers against it that
As we discussed on IRC last night, I think these changes are perfectly
reasonable (in fact just what I'd expect if we moved to this model).
Sure, it will force contributors to be more disciplined, but that's
probably a good thing anyway. I'd still like to hear from the BSD guys
about
Then this, the thing is to keep it building you need compat code, code
that can't go into Linus tree, so we end up with a tree that isn't like
Linus tree, and we still have to patch manage transitions so we don't save
anything doing this over what we have now.
I was thinking that
