Re: [rfc][patch 2/3] xfs: remove vmap cache
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 expensive parts of the operation
being the broadcast IPIs and locking involved in the SMP callouts, and the
locking involved in the vmap management -- none of these are avoided by just
batching up the calls. I'm actually surprised it ever made much difference
at all.
So am I.
Rip all this logic out of XFS completely. I improve vmap performance
and scalability directly in the previous and subsequent patch.
Sounds good to me.
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.c
+++ linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
@@ -166,75 +166,6 @@ test_page_region(
}
/*
- * Mapping of multi-page buffers into contiguous virtual space
- */
-
-typedef struct a_list {
- void*vm_addr;
- struct a_list *next;
-} a_list_t;
-
-static a_list_t *as_free_head;
-static int as_list_len;
-static DEFINE_SPINLOCK(as_lock);
-
-/*
- * Try to batch vunmaps because they are costly.
- */
-STATIC void
-free_address(
- void*addr)
-{
- a_list_t*aentry;
-
-#ifdef CONFIG_XEN
- /*
- * Xen needs to be able to make sure it can get an exclusive
- * RO mapping of pages it wants to turn into a pagetable. If
- * a newly allocated page is also still being vmap()ed by xfs,
- * it will cause pagetable construction to fail. This is a
- * quick workaround to always eagerly unmap pages so that Xen
- * is happy.
- */
- vunmap(addr);
- return;
-#endif
-
- aentry = kmalloc(sizeof(a_list_t), GFP_NOWAIT);
- if (likely(aentry)) {
- spin_lock(as_lock);
- aentry-next = as_free_head;
- aentry-vm_addr = addr;
- as_free_head = aentry;
- as_list_len++;
- spin_unlock(as_lock);
- } else {
- vunmap(addr);
- }
-}
-
-STATIC void
-purge_addresses(void)
-{
- a_list_t*aentry, *old;
-
- if (as_free_head == NULL)
- return;
-
- spin_lock(as_lock);
- aentry = as_free_head;
- as_free_head = NULL;
- as_list_len = 0;
- spin_unlock(as_lock);
-
- while ((old = aentry) != NULL) {
- vunmap(aentry-vm_addr);
- aentry = aentry-next;
- kfree(old);
- }
-}
-
-/*
* Internal xfs_buf_t object manipulation
*/
@@ -334,7 +265,7 @@ xfs_buf_free(
uinti;
if ((bp-b_flags XBF_MAPPED) (bp-b_page_count 1))
- free_address(bp-b_addr - bp-b_offset);
+ vunmap(bp-b_addr - bp-b_offset);
for (i = 0; i bp-b_page_count; i++) {
struct page *page = bp-b_pages[i];
@@ -456,8 +387,6 @@ _xfs_buf_map_pages(
bp-b_addr = page_address(bp-b_pages[0]) + bp-b_offset;
bp-b_flags |= XBF_MAPPED;
} else if (flags XBF_MAPPED) {
- if (as_list_len 64)
- purge_addresses();
bp-b_addr = vmap(bp-b_pages, bp-b_page_count,
VM_MAP, PAGE_KERNEL);
if (unlikely(bp-b_addr == NULL))
@@ -1739,8 +1668,6 @@ xfsbufd(
count++;
}
- if (as_list_len 0)
- purge_addresses();
if (count)
blk_run_address_space(target-bt_mapping);
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc][patch 3/3] xfs: use new vmap API
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
===
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf.c
+++ linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
@@ -265,7 +265,7 @@ xfs_buf_free(
uinti;
if ((bp-b_flags XBF_MAPPED) (bp-b_page_count 1))
- vunmap(bp-b_addr - bp-b_offset);
+ vm_unmap_ram(bp-b_addr - bp-b_offset,
bp-b_page_count);
for (i = 0; i bp-b_page_count; i++) {
struct page *page = bp-b_pages[i];
@@ -387,8 +387,8 @@ _xfs_buf_map_pages(
bp-b_addr = page_address(bp-b_pages[0]) + bp-b_offset;
bp-b_flags |= XBF_MAPPED;
} else if (flags XBF_MAPPED) {
- bp-b_addr = vmap(bp-b_pages, bp-b_page_count,
- VM_MAP, PAGE_KERNEL);
+ bp-b_addr = vm_map_ram(bp-b_pages, bp-b_page_count,
+ -1, PAGE_KERNEL);
if (unlikely(bp-b_addr == NULL))
return -ENOMEM;
bp-b_addr += bp-b_offset;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16982] New: Problems with DRM on G33 chipset
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 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I use FREEBSD 7.0-CURRENT, and Xorg 7.3 compiled from the ports (all less than 1 week ago). I use the AMD64 version on a Intel E2180 CPU. My graphic card is an Intel G33 chipset. I had to modify kernel sources to get Xorg work (G33 lines were commented out in agp_i810.c), but DRM is still not working. Here are some logs : stage003:~ # kldstat Id Refs AddressSize Name 17 0x8010 b2dc98 kernel 21 0xaf641000 aa7a fuse.ko 31 0xaf64c000 4ba7 i915.ko 41 0xaf651000 d5d8 drm.ko stage003:~ # dmesg|grep drm - nothing stage003:~ # grep -i drm /var/log/Xorg.0.log drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -2 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed [snip] drmOpenByBusid: drmOpenMinor returns -2 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed [drm] failed to load kernel module i915 (EE) [drm] drmOpen failed. then the Intel driver reports : (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. stage003:~ # cat /usr/local/etc/X11/xorg.conf Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection Section Files RgbPath /usr/local/share/X11/rgb ModulePath /usr/local/lib/xorg/modules FontPath /usr/local/lib/X11/fonts/misc/ FontPath /usr/local/lib/X11/fonts/TTF/ FontPath /usr/local/lib/X11/fonts/OTF FontPath /usr/local/lib/X11/fonts/Type1/ FontPath /usr/local/lib/X11/fonts/100dpi/ FontPath /usr/local/lib/X11/fonts/75dpi/ EndSection Section Module Load extmod Load record Load dbe Load glx Load GLcore Load xtrap Load dri Load freetype Load type1 EndSection Section InputDevice Identifier Keyboard0 Driver kbd Option XkbModel pc105 Option XkbLayout fr EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/sysmouse Option ZAxisMapping 4 5 6 7 EndSection Section Monitor Identifier Monitor0 VendorName Dell ModelNameE177FP HorizSync31-81 VertRefresh 56-76 ModeLine 1280x1024 108.0 1280 1328 1440 1688 1024 1025 1028 1066 Option DPMS EndSection Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option ShadowFB # [bool] #Option DefaultRefresh# [bool] #Option ModeSetClearScreen# [bool] Identifier Card0 #Driver vesa #Driver i810 Driver intel VendorName Intel Corporation BoardName 82G33/G31 Express Integrated Graphics Controller BusID PCI:0:2:0 EndSection Section Screen Identifier Screen0 Device Card0 MonitorMonitor0 DefaultDepth 24 Option AddARGBGLXVisuals True SubSection Display Viewport 0 0 Depth 24 Modes 1280x1024 EndSubSection EndSection Section Extensions Option Composite Enable EndSection Section DRI Mode 0666 EndSection -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving
Re: [rfc][patch 3/3] xfs: use new vmap API
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. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1] Adapt on_each_cpu
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 it is to simply update the DRM drivers and build against my current kernel (or just updating a theoretical DRM kernel tree building for that matter). So really I don't think keeping compat *in-tree* for old kernels gives us extra testing. It's really no harder or easier to do the same thing with a full kernel tree, just different. IMO anyway. Yeah, we could keep the BC code around if we moved the drivers in-tree, and that would let you compile the drivers against an older kernel using something like: First you said this :).. Another benefit from having the DRM repo structured as linux kernel tree is that changes from upstream linux development (janitorial stuff, tree-wide api changes) only takes a 'git merge' to carry over to the DRM tree. In other words, making it easier to push changes upstream works both ways, it also becomes easier to pull down changes from upstream that touches the DRM subystem. Hm, I guess that's what your saying in 4). 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 having the BC code in-tree might be acceptable. As far as I remember, the old firewire stack did that for a while, but maybe they've tightened up the policy on that. So, I very much agree with your proposal and don't feel I can add much, except to point out that a migration to in-tree drm development doesn't need to be a big and painful process. Basically, we just decide to do it, and designate a kernel tree on freedesktop.org that we work from and start with the current state of upstream drm. There will be some work in moving things over from drm.git to the kernel tree, but we were going to do that *anyway* as part of getting it upstream. What will be different is that Dave won't have to do all that work, we can split it up between us and all Dave will need to do is to merge the branch and push it to Linus. This is of course what Eric is already doing with GEM in people.fd.o/~anholt/linux-2.6, and that would be a great way to get the vblank rework upstream too. If we do this, I'm going to introduce new rules for features/patches that will put a lot more work on people. 1. Nobody gets commit access to master branch except me. 2. All work is done in topic branches that are throwaway once complete. So when the branch owner decides the work is upstreamable, They create a set of clean patches against the current master, send them to dri-devel for review, if they pass review then the branch owner creates a new clean branch and asks me to merge it, it also includes Signed-off-by lines. Some people say we want the history, Linus wants bisectable history so invariable when a feature reaches a useful stage it should go upstream in clean s-o-b patches that are bisectable and pass checkpatch.pl, not in a 50 separate patches with fixes in it. We can generate a throwaway drm-next tree that merges all the topic branches currently in play if people want to have some superview. 3. All API changes to go to the list as soon as possible (should be done now). That all sounds good to me, I think we will benefit from a little stricter process instead of the free-for-all drm.git repo we have now. And topic branches sounds very promising; if GEM had been done in a topic branch off of the upstream linux tree, preparing the patch would literally be one git diff command, instead of having to sort out the GEM changes from drm.git. Similarly, Ian's XGI work wouldn't have used the ttm fences and gotten upstream faster. Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1] Adapt on_each_cpu
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 how we can best keep shareable code obvious and contribution conditions clear, but so far I haven't heard any serious problems. Well, I'm only like a third of a developer, but I'll give it a shot. You are correct that the most important thing for me is being able to readily identify what code is or should be portable and licensed appropriately. I suppose in many ways this is easier for oga to swallow because he already works in his own tree. I however work entirely out of drm.git and just drop that into our cvs/svn tree for releases. If we move to a linux tree, does that mean that I will have to pull a full linux git tree and then try to hand pick the drm bits out? Yeah, that's what I'd expect. Where would the bsd specific code live? I guess it would be in the apprpriate BSD CVS or something? What about libdrm? That should probably be in its own repo. Do I have to setup my own repo for the bsd parts and just try to merge stuff from the linux tree? Yeah, although given what Dave mentioned, you'd also see patches proposed submitted more visibly on dri-devel before going into the repo. A BSD DRM maintainer could actually setup a separate, BSD specific repo along the lines of the Linux one, and merge patches just like Dave will be doing for Linux. That might be easiest (and who knows, maybe even better than what we have currently from a BSD perspective). As for BC, as the code stands now, the bsd side of the house has a few ifdefs that enable certain features from certain releases of bsd, but it pretty much can just drop into any 6,7,8 release as-is. That may become more of a pain as I try and rework various code paths taking advantage of newer features, but for now it mostly just works. Sounds like the BSD camp moves its internal APIs a bit more slowly than Linux. Certainly makes things easier for driver people... I realize that some of the new features KMS and GEM are relying much more heavily on specific kernel features, which already makes my task daunting. I don't think that anyone is intentionally trying to make things more difficult, but I don't see how this move doesn't make it even more difficult for me to try and keep pace with linux crowd. I know I need help already and if I have to keep up with every patch and bugfix that goes in and cherry-pick it, I won't have time to do much else. If anything, I think this will actually slow down the pace of commits on the Linux side. We should see fewer, higher quality commits than under the current scheme, so with a BSD gatekeeper setup like I mentioned above things might even get easier... Thanks, Jesse - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1] Adapt on_each_cpu
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 having the BC code in-tree might be acceptable. As far as I remember, the old firewire stack did that for a while, but maybe they've tightened up the policy on that. Not allowed anymore, including version.h is a red flag nowadays.. stricter process instead of the free-for-all drm.git repo we have now. And topic branches sounds very promising; if GEM had been done in a topic branch off of the upstream linux tree, preparing the patch would literally be one git diff command, instead of having to sort out the GEM changes from drm.git. Similarly, Ian's XGI work wouldn't have used the ttm fences and gotten upstream faster. Well XGI isn't going upstream as last I heard from IBM it still didn't work, and they scrapped the XGI plan and bought a bunch of X1650s once Ben and myself fixed the endianness issues. While I'd like to believe preparing the patch would be one git diff away, I suspect it would have been 15 cherry-picks, a couple of merges, a few interactive rebases and a batch of checkpatch.pls away. Nothing is ever a git diff away from upstream. So we would need to find a way to get all the compat hacks into two/three files with no version checks in the actual code. Sounds icky. Or someone who cared enough would need to maintain a separate repo for old kernels. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
