similar to: [PATCH] Fix performance problems with mprotect()

From: "Bruce Rogers" <brogers at novell.com> Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing these tests for extended periods of time. Make sure napi is scheduled subsequent to each napi_enable. Signed-off-by: Bruce Rogers <brogers at

From: "Bruce Rogers" <brogers at novell.com> Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing these tests for extended periods of time. Make sure napi is scheduled subsequent to each napi_enable. Signed-off-by: Bruce Rogers <brogers at

Hi, 2.6.29-rc3 x86_64 guest on x86_64 RHEL5.3 host: https://bugzilla.redhat.com/484295 kernel BUG at mm/filemap.c:123! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/vbd-51712/block/xvda/xvda2/dev CPU 0 Modules linked in: ipv6 xts lrw gf128mul sha256_generic cbc dm_crypt

Hey folks, This is the part-of-pvops-implementation-that-is-not-exactly-a-merge. Neat, uh? This is the majority of the work. The first patch in the series does not really belong here. It was already sent to lkml separetedly before, but I'm including it again, for a very simple reason: Try to test the paravirt patches without it, and you'll fail miserably ;-) (and it was not yet

Hey folks, This is the part-of-pvops-implementation-that-is-not-exactly-a-merge. Neat, uh? This is the majority of the work. The first patch in the series does not really belong here. It was already sent to lkml separetedly before, but I'm including it again, for a very simple reason: Try to test the paravirt patches without it, and you'll fail miserably ;-) (and it was not yet

I just noticed that the linux block backend does not copy the full 64 bits of the id field of a request to the associated response. The blkif.h states that this is echoed in the response. An unsigned long in make_response is used as an intermediary. This would sure be helpful to me if the full 64 bits were echoed. - Bruce Rogers _______________________________________________ Xen-devel

The paravirtualized guests are offered wallclock time referenced to UTC only, while fully virtualized guests are given the option via the config file (localtime parameter) of starting with UTC time or local time. What would it take to optionally provide localtime to the paravirtualized guests as well? For a guest that launches assuming localtime as its time basis, then later deriving UTC from it

Here is an slightly updated version of the paravirt_ops patch. If your comments and criticism were welcome before, now it's even more! There are some issues that are _not_ addressed in this revision, and here are the causes: * split debugreg into multiple functions, suggested by Andi: - Me and jsfg agree that introducing more pvops (specially 14!) is not worthwhile. So, although we do

Here is an slightly updated version of the paravirt_ops patch. If your comments and criticism were welcome before, now it's even more! There are some issues that are _not_ addressed in this revision, and here are the causes: * split debugreg into multiple functions, suggested by Andi: - Me and jsfg agree that introducing more pvops (specially 14!) is not worthwhile. So, although we do

On Fri, Jun 04, 2010 at 10:28:56AM +0930, Rusty Russell wrote: > This patch is a subset of an already upstream patch, but this portion > is useful in earlier releases. > > Please consider for the 2.6.32 and 2.6.33 stable trees. > > If the add_buf operation fails, indicate failure to the caller. > > Signed-off-by: Bruce Rogers <brogers at novell.com> >

On Fri, Jun 04, 2010 at 10:28:56AM +0930, Rusty Russell wrote: > This patch is a subset of an already upstream patch, but this portion > is useful in earlier releases. > > Please consider for the 2.6.32 and 2.6.33 stable trees. > > If the add_buf operation fails, indicate failure to the caller. > > Signed-off-by: Bruce Rogers <brogers at novell.com> >

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

This is hopefully the last iteration of the pvops64 patch. >From the last version, we have only one change, which is include/asm-x86_64/processor.h: There were still one survivor in raw asm. Also, git screwed me up for some reason, and the 25th patch was missing the new files, paravirt.{c,h}. (although I do remember having git-add'ed it, but who knows...) Andrew, could you please push it

This is hopefully the last iteration of the pvops64 patch. >From the last version, we have only one change, which is include/asm-x86_64/processor.h: There were still one survivor in raw asm. Also, git screwed me up for some reason, and the 25th patch was missing the new files, paravirt.{c,h}. (although I do remember having git-add'ed it, but who knows...) Andrew, could you please push it

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),