Re: [PATCH RFC net-next] virtio_net: refill buffer right after being used

On Sat, Jul 30, 2011 at 10:16:15PM -0700, Shirley Ma wrote: > It averages the latency between each receive by filling only one set of > buffers vs. either none buffers or 1/2 ring size buffers fill between > receives. I see how the overhead of allocating memory is spread more evenly. Does this ac

Re: [PATCH RFC net-next] virtio_net: refill buffer right after being used

On Fri, Jul 29, 2011 at 03:55:31PM -0700, Shirley Ma wrote: > Resubmit it with a typo fix. > > Signed-off-by: Shirley Ma > --- > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 0c7321c..c8201d4 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c >

Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes

On Wed, Aug 03, 2011 at 06:15:33PM +0200, Gerd Hoffmann wrote: > Hi, > > >E.g. with 32 bridges, and 32 devices behind each one, > >the available 64K space gets us only 64 bytes per device. > > 15 bridges (with io window enabled) max, the smallest io window you > can assign to a bridge is 4k, an

Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes

On Wed, Aug 03, 2011 at 06:15:33PM +0200, Gerd Hoffmann wrote: > Hi, > > >E.g. with 32 bridges, and 32 devices behind each one, > >the available 64K space gets us only 64 bytes per device. > > 15 bridges (with io window enabled) max, the smallest io window you > can assign to a bridge is 4k, H

Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes

Hi, > E.g. with 32 bridges, and 32 devices behind each one, > the available 64K space gets us only 64 bytes per device. 15 bridges (with io window enabled) max, the smallest io window you can assign to a bridge is 4k, and you need some space for the devices on the root bus ... cheers, Ge

Re: [PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes

On Thu, Jun 02, 2011 at 11:19:35AM +0930, Rusty Russell wrote: > On Wed, 1 Jun 2011 13:25:48 +0300, "Michael S. Tsirkin" > wrote: > > Add an option to modify the notificatin > > hand-off in virtio to be basically like Xen: > > each side published an index, the other side only triggers > > an even

Re: [PATCH v2 0/6] Collected vdso/vsyscall fixes for 3.1

On Wed, Aug 3, 2011 at 9:56 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Aug 03, 2011 at 09:53:22AM -0400, Konrad Rzeszutek Wilk wrote: >> On Wed, Aug 03, 2011 at 09:31:48AM -0400, Andy Lutomirski wrote: >> > This fixes various problems that cropped up with the vdso patches. >> > >> >  - Patch 1 fix

Re: [PATCH v2 0/6] Collected vdso/vsyscall fixes for 3.1

On Wed, Aug 03, 2011 at 09:53:22AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Aug 03, 2011 at 09:31:48AM -0400, Andy Lutomirski wrote: > > This fixes various problems that cropped up with the vdso patches. > > > > - Patch 1 fixes an information leak to userspace. > > - Patches 2 and 3 fix the

[PATCH v2 1/6] x86-64: Pad vDSO to a page boundary

This avoids an information leak to userspace. Signed-off-by: Andy Lutomirski --- arch/x86/vdso/vdso.S |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/vdso/vdso.S b/arch/x86/vdso/vdso.S index 1b979c1..01f5e3b 100644 --- a/arch/x86/vdso/vdso.S +++ b/arch/x86/vdso/

Re: [PATCH v2 0/6] Collected vdso/vsyscall fixes for 3.1

On Wed, Aug 03, 2011 at 09:31:48AM -0400, Andy Lutomirski wrote: > This fixes various problems that cropped up with the vdso patches. > > - Patch 1 fixes an information leak to userspace. > - Patches 2 and 3 fix the kernel build on gold. > - Patches 4 and 5 fix Xen (I hope). > - Patch 6 (optio

Re: [PATCH v2 4/6] x86-64/xen: Enable the vvar mapping

On Wed, Aug 03, 2011 at 09:31:52AM -0400, Andy Lutomirski wrote: > Xen needs to handle VVAR_PAGE, introduced in git commit: > 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 > x86-64: Give vvars their own page > > Otherwise we die during bootup with a message like: > > (XEN) mm.c:940:d10 Error getting m

[PATCH v2 5/6] x86-64: Add user_64bit_mode paravirt op

Three places in the kernel assume that the only long mode CPL 3 selector is __USER_CS. This is not true on Xen -- Xen's sysretq changes cs to the magic value 0xe033. Two of the places are corner cases, but as of "x86-64: Improve vsyscall emulation CS and RIP handling" (c9712944b2a12373cb6ff8059af

[PATCH v2 4/6] x86-64/xen: Enable the vvar mapping

Xen needs to handle VVAR_PAGE, introduced in git commit: 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 x86-64: Give vvars their own page Otherwise we die during bootup with a message like: (XEN) mm.c:940:d10 Error getting mfn 1888 (pfn 1e3e48) from L1 entry 81888465 for l1e_owner=10, pg_

[PATCH v2 6/6] x86-64: Add vsyscall:emulate_vsyscall trace event

Vsyscall emulation is slow, so make it easy to track down. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/vsyscall_64.c|6 ++ arch/x86/kernel/vsyscall_trace.h | 29 + 2 files changed, 35 insertions(+), 0 deletions(-) create mode 100644 arch/x86/kern

[PATCH v2 3/6] x86-64: Work around gold bug 13023

Gold has trouble assigning numbers to the location counter inside of an output section description. The bug was triggered by 9fd67b4ed0714ab718f1f9bd14c344af336a6df7, which consolidated all of the vsyscall sections into a single section. The workaround is IMO still nicer than the old way of doing

[PATCH v2 2/6] x86-64: Move the "user" vsyscall segment out of the data segment.

The kernel's loader doesn't seem to care, but gold complains. Signed-off-by: Andy Lutomirski Reported-by: Arkadiusz Miskiewicz --- arch/x86/kernel/vmlinux.lds.S | 36 ++-- 1 files changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/vmlinux.

[PATCH v2 0/6] Collected vdso/vsyscall fixes for 3.1

This fixes various problems that cropped up with the vdso patches. - Patch 1 fixes an information leak to userspace. - Patches 2 and 3 fix the kernel build on gold. - Patches 4 and 5 fix Xen (I hope). - Patch 6 (optional) adds a trace event to vsyscall emulation. It will make it easier to