bridge up/downstream capability registers
after PM event. This includes maxumum split transaction
commitment limit which might be vital for PCI X.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index df49530..4b788ef 100644
Quoting Adrian Bunk [EMAIL PROTECTED]:
Subject: [2/6] 2.6.21-rc2: known regressions
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Status : unknown
Here's the status with -rc3
Quoting Linus Torvalds [EMAIL PROTECTED]:
Here's the status with -rc3: better, but still does not work as well as
2.6.20.
Ok. I think we mostly solved the irq-related stuff, but you might want to
check whether you have CONFIG_NOHZ on or off and whether that makes a
difference.
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [2/6] 2.6.21-rc2: known regressions
* Linus Torvalds [EMAIL PROTECTED] wrote:
3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of
windows
after waiting for some 10 min, I rebooted. no new messages showed
2. First disk access after resume takes a couple of minutes
(seemed instant with 2.6.20) during this time no new messages show on
console
Yeah, there is some problem with SATA resume. It would be beautiful if the
people who actually see this could narrow it down with bisection. It
Quoting Eric W. Biederman [EMAIL PROTECTED]:
Subject: Re: SATA resume slowness, e1000 MSI warning
Michael S. Tsirkin [EMAIL PROTECTED] writes:
The only case I can see which might trigger this is if we saved
pci-X state and then didn't restore it because we could not find
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: IPoIB caused a kernel: BUG: soft lockup detected on CPU#0!
Feb 27 17:47:52 sw169 kernel: [8053aaf1]
_spin_lock_irqsave+0x15/0x24
Feb 27 17:47:52 sw169 kernel: [88067a23]
:ib_ipoib:ipoib_neigh_destructor+0xc2/0x139
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: lockdep question (was Re: IPoIB caused a kernel: BUG: soft
lockup detected on CPU#0!)
After adding some printks, I started getting these:
[ 597.036720] BUG: MAX_STACK_TRACE_ENTRIES too low!
[ 597.041546] turning off
After adding some printks, I started getting these:
[ 597.036720] BUG: MAX_STACK_TRACE_ENTRIES too low!
[ 597.041546] turning off the locking correctness validator.
[ 597.047135] [c023a922] save_trace+0x8a/0x8f
[ 597.051751] [c023ae8c] mark_lock+0x65/0x3ff
[ 597.056366] [c023a8d6]
Quoting Peter Zijlstra [EMAIL PROTECTED]:
Subject: Re: lockdep question (was Re: IPoIB caused a kernel: BUG: softlockup
detected on CPU#0!)
On Sun, 2007-03-11 at 15:50 +0200, Michael S. Tsirkin wrote:
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: IPoIB caused a kernel: BUG: soft
Rumor has it that some pci devices can't tolerate 32bit accesses.
Although I have never met one.
hopefully not bridge devices?
The two factors together suggest that
for generic code it probably makes sense to operate on 32bit
quantities, and just to ignore the read-only portion.
The code
Quoting Eric W. Biederman [EMAIL PROTECTED]:
Subject: Re: SATA resume slowness, e1000 MSI warning
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Rumor has it that some pci devices can't tolerate 32bit accesses.
Although I have never met one.
hopefully not bridge devices?
The two
Quoting Eric W. Biederman [EMAIL PROTECTED]:
Subject: Re: SATA resume slowness, e1000 MSI warning
Michael S. Tsirkin [EMAIL PROTECTED] writes:
OK I guess. I gather we assume writing read-only registers has no side
effects?
Are there rumors circulating wrt to these?
I haven't heard
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [2/6] 2.6.21-rc2: known regressions
Michael,
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
2. First disk access after resume takes a couple of minutes
(seemed instant with 2.6.20) during this time no new messages show
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: lockdep question (was Re: IPoIB caused a kernel: BUG: softlockup
detected on CPU#0!)
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
So either there are other sites that instanciate those objects and
forget about the lock init
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: lockdep question (was Re: IPoIB caused a kernel: BUG: softlockup
detected on CPU#0!)
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
could you turn on CONFIG_SLAB_DEBUG as well?
that should catch certain types of use-after-free
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [2/6] 2.6.21-rc2: known regressions
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [2/6] 2.6.21-rc2: known regressions
Michael,
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
2. First disk access after
Alexey, Roland,
In debugging kernel lockup that occurs with IP over InfiniBand in 2.6.21-rc4:
( https://bugs.openfabrics.org/show_bug.cgi?id=402 )
I noticed the following code in dst_ifdown:
/* Dirty hack. We did it in 2.2 (in __dst_free),
* we have _very_ good reasons not to repeat
* this
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
This is not new code, and should have triggered long time ago,
so I am not sure how come we are triggering this only now,
but somehow this did not lead to crashes in 2.6.20
I see. I guess
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
This is not new code, and should have triggered long time ago,
so I am not sure how come we are triggering this only now,
but somehow this did not lead to crashes in 2.6.20
I see. I guess
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
Hmm. Something I don't understand: does the code
in question not run on *each* device unregister?
It does.
Why do I only see this under stress?
You should have some referenced
Why is neighbour-dev changed here?
It holds reference to device and prevents its destruction.
If dst is held somewhere, we cannot destroy the device and deadlock
while unregister.
BTW, can this ever happen for the loopback device itself?
Is it ever unregistered?
--
MST
-
To unsubscribe
It should be cleared and we should be sure it will not be destroyed
before quiescent state.
I'm confused. didn't you say dst_ifdown is called after quiescent state?
Quiescent state should happen after dst-neighbour is invalidated.
And this implies that all the users of dst-neighbour
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Can dst-neighbour be changed to point to NULL instead, and the neighbour
released?
It should be cleared and we should be sure it will not be destroyed
before quiescent state.
Seems, this is the only
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Can dst-neighbour be changed to point to NULL instead, and the neighbour
released?
It should be cleared
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Can dst
Quoting Eric W. Biederman ebiederman@lnxi.com:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Why is neighbour-dev changed here?
It holds reference to device and prevents its destruction.
If dst is held somewhere, we
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Quoting Eric W. Biederman ebiederman@lnxi.com:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Why is neighbour
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Quoting
Quoting David Miller [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 00:42:34 +0200
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks
, but the
list_for_each_entry() for() loop uses it.
Something like this then? Untested.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 12b528b..706eb88 100644
--- a/drivers/infiniband/ulp/ipoib
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Does this look sane (untested)?
It does not, unfortunately.
Instead of regular crash in infiniband you will get numerous
random NULL pointer dereferences both due to dst-neighbour
.
This is an old bug, but apparently, started to get triggered more infiniband
after recent multicast and connected mode changes.
Fix this by delaying dev_put until the neigh_params object is removed.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/net/core/neighbour.c b/net/core
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Any simpler ideas?
Well, if inifiniband destructor really needs to take that lock... no.
Right now I do not see.
OK, this is actually not hard to fix - for infiniband, we can just look
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
If a device driver sets neigh_destructor in neigh_params, this could
get called after the device has been unregistered and the driver module
removed.
It is the same problem: if
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
If a device driver sets neigh_destructor in neigh_params, this could
get called after the device has been unregistered and the driver module
removed.
It is the same problem: if
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
infiniband sets parm-neigh_destructor, and I search for a way to prevent
this destructor from being called after the module has been unloaded.
Ideas?
It must be called in any case to
are experiencing these crashes.
David, Alexey, what do you think about this patch? Is it right?
Could this patch be considered for 2.6.21?
Acked-by: Michael S. Tsirkin [EMAIL PROTECTED]
I think this is enough for ipoib which is the only user of this thing.
Initialization private part
- Without CONFIG_NO_HZ
I last tested this with cd05a1f818073a623455a58e756c5b419fc98db9.
After systems comes out of suspend to ram, I observed the following
behaviour (I used s2ram from console):
1. The first disk access takes much longer than with 2.6.20
2. System clock does
Quoting Thomas Gleixner [EMAIL PROTECTED]:
Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote:
Can you please test the following:
Add clocksource=acpi_pm to the kernel commandline.
If this does not change anything
Quoting Thomas Gleixner [EMAIL PROTECTED]:
Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 12:15 +0200, Michael S. Tsirkin wrote:
Quoting Thomas Gleixner [EMAIL PROTECTED]:
Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Sun, 2007-03-25 at 10
Update: I tested 2.6.21-rc5 with the following settings
# CONFIG_NO_HZ is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_HPET is not set
1. Without additional kernel options
After systems comes out of suspend to ram, I observed the following
behaviour (I used s2ram from
Quoting Andrew Morton [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: T60 resume from suspend to RAM issues
On Fri, 23 Feb 2007 01:38:03 +0200 Michael S. Tsirkin [EMAIL PROTECTED]
wrote:
I tested this:
commit 9654640d0af8f2de40ff3807d3695109d3463f54
and see 2 issues:
1. After
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: T60 resume from suspend to RAM issues
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
2. As a separate test, I enabled DynTicks in .config. Seems to
work fine but won't come out of suspend to memory at all: pressing
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: T60 resume from suspend to RAM issues
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Do you believe that the second problem was caused by dynticks?
Assuming these are 2 different problems, yes, the second one
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Handled-By : Ingo Molnar [EMAIL PROTECTED]
Status : unknown
Just reproduced this in -rc2.
Another thing I noticed:
with 2.6.20, pressing
Quoting Thomas Gleixner [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
On Wed, 2007-02-28 at 23:13 +0200, Michael S. Tsirkin wrote:
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: [patch] KVM: T60 resume fix
From: Ingo Molnar [EMAIL PROTECTED]
my T60 laptop does not resume correctly due to KVM attempting to send an
IPI to a CPU that might be down (or not up yet). (Doing so also triggers
the send_IPI_mask_bitmask()
Quoting Pavel Machek [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (part 2)
Hi!
* Jens Axboe [EMAIL PROTECTED] wrote:
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
Quoting Avi Kivity [EMAIL PROTECTED]:
Subject: Re: [patch] KVM: T60 resume fix
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
suspend/resume works fine now and there are no warning messages
whatsoever (with suspend simulation). Thanks Avi!
Where do I find
with this fix applied my laptop does not hang during resume.
On the off chance that this is relevant, could you post
your .config please?
--
MST
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
suspend/resume works fine now and there are no warning messages
whatsoever (with suspend simulation). Thanks Avi!
I just tried Ingo's .config and it hangs on resume for me (with suspend to
memory).
--
MST
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [patch] KVM: T60 resume fix
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
suspend/resume works fine now and there are no warning messages
whatsoever (with suspend simulation). Thanks Avi!
I just tried Ingo's .config
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (part 2)
* Jens Axboe [EMAIL PROTECTED] wrote:
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (part 2)
* Ingo Molnar [EMAIL PROTECTED] wrote:
I'll try what i've described in the previous mail: mark all bisection
points that do not include f3ccb06f as 'good' - thus 'merging' the
known-bad area
Quoting Ingo Molnar [EMAIL PROTECTED]:
git-bisect good 0539771d7236b425f285652f6f297cc7939c8f9a
81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
I have confirmed these two on my system.
--
MST
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Quoting Linus Torvalds [EMAIL PROTECTED]:
Ok, it does indeed solve the problem for me.
Not yet for me unfortunately, although this seems to help.
Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445
With this applied, on resume I get *some* screen output soon after
Quoting Linus Torvalds [EMAIL PROTECTED]:
Ok, it does indeed solve the problem for me.
Not yet for me unfortunately, although this seems to help.
Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445
With this applied, on resume I get *some* screen output soon after
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [5/6] 2.6.21-rc2: known regressions
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Linus Torvalds [EMAIL PROTECTED]:
Ok, it does indeed solve the problem for me.
Not yet for me unfortunately, although this seems
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [5/6] 2.6.21-rc2: known regressions
* Soeren Sonnenburg [EMAIL PROTECTED] wrote:
BTW, Ingo, can you suspend/resume any number of times with this
patch?
well I could at least two times in a row in my minimalistic setup
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [5/6] 2.6.21-rc2: known regressions
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Not yet for me unfortunately, although this seems to help.
Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [5/6] 2.6.21-rc2: known regressions
* Ingo Molnar [EMAIL PROTECTED] wrote:
BTW, Ingo, can you suspend/resume any number of times with this
patch?
well I could at least two times in a row in my minimalistic setup
(config
Quoting Jeff Chua [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
On 3/6/07, Jeff Chua [EMAIL PROTECTED] wrote:
On 3/5/07, Adrian Bunk [EMAIL PROTECTED] wrote:
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
from RAM, can't suspend
commitment limit which might be vital for PCI X.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index df49530..4b788ef 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev
Subject: first disk access after resume takes several minutes
('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
http://lkml.org/lkml/2007/3/25/20
Submitter : Michael S. Tsirkin [EMAIL PROTECTED
Subject: after resume: X hangs after drawing a couple of windows
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117
http://lkml.org/lkml/2007/3/25/20
http://lkml.org/lkml/2007/3/26/151
Submitter : Michael S. Tsirkin
Subject: after resume: X hangs after drawing a couple of windows
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117
http://lkml.org/lkml/2007/3/25/20
http://lkml.org/lkml/2007/3/26/151
Submitter : Michael S. Tsirkin
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: InfiniBand/RDMA merge plans for 2.6.24
With 2.6.24 probably opening in the not-too-distant future, it's
probably a good time to review what my plans are for when the merge
window opens.
Roland, could you merge the common TX CQ patch please?
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: InfiniBand/RDMA merge plans for 2.6.24
Roland, could you merge the common TX CQ patch please?
It actually fixes a real problem.
Yes, I will, but it collides with the net-2.6.24 NAPI rework I think,
so it may not go in until a few
On Tue, Sep 11, 2012 at 12:10:18AM +0300, Michael S. Tsirkin wrote:
On the plus side, having an exit taken here on each page turns out to
be relatively cheap, as the vmexit from the page fault should be
faster to process as it is fully handled within the host kernel.
Perhaps some
On Tue, Oct 30, 2012 at 11:47:45AM -0400, Vlad Yasevich wrote:
On 10/29/2012 11:49 AM, Michael S. Tsirkin wrote:
It seems that to avoid deadlocks it is enough to poll vq before
we are going to use the last buffer. This should be faster than
c70aa540c7a9f67add11ad3161096fb95233aa2e
On Tue, Oct 30, 2012 at 11:44:16AM -0400, Vlad Yasevich wrote:
On 10/29/2012 11:49 AM, Michael S. Tsirkin wrote:
Orphaning frags for zero copy skbs needs to allocate data in atomic
context so is has a chance to fail. If it does we currently discard
the skb which is safe, but we don't report
this into account
and switch to copying in user context.
This patch updates all users but ignores the passed value for now:
it will be used by follow-up patches.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vhost.h | 2 +-
include/linux
such errors: this is used
by tun in case orphaning frags fails.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/skbuff.h | 1 +
net/core/skbuff.c | 20
2 files changed, 21 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8bac11b
This will be used to disable zerocopy when error rate
is high.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/vhost.c | 7 ---
drivers/vhost/vhost.h | 4
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
When tun transmits a zero copy skb, it orphans the frags
which might need to allocate extra memory, in atomic context.
If that fails, notify ubufs callback before freeing the skb
as a hint that device should disable zerocopy mode.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/net
Better document macros for DMA tracking. Add an
explicit one for DMA in progress instead of
relying on user supplying len != 1.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 3 ++-
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vhost.h | 12 +---
3 files
Zerocopy handling code is vhost-net specific.
Move it from vhost.c/vhost.h out to net.c
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 45
drivers/vhost/tcm_vhost.c | 1 +
drivers/vhost/vhost.c | 53
for guest to guest
and guest to host traffic.
To fix this, suppress zero copy tx after a given number of
packets triggered late data copy. Re-enable periodically
to detect workload changes.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 55
It seems that to avoid deadlocks it is enough to poll vq before
we are going to use the last buffer. This is faster than
c70aa540c7a9f67add11ad3161096fb95233aa2e.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 14 --
1 file changed, 12 insertions(+), 2
for
guest to host and guest to guest both with and without zero copy tx.
Changes from v1:
Comment fixups in patches 2 and 8 suggested by Vlad Yasevich,
no changes to other patches
Michael S. Tsirkin (8):
skb: report completion status for zero copy skbs
skb: api to report errors for zero
On Thu, Nov 01, 2012 at 11:50:24AM -0400, David Miller wrote:
From: Michael S. Tsirkin m...@redhat.com
Date: Wed, 31 Oct 2012 12:31:06 +0200
-void vhost_zerocopy_callback(struct ubuf_info *ubuf)
+void vhost_zerocopy_callback(struct ubuf_info *ubuf, int zerocopy_status)
If you're only
Michael S. Tsirkin (8):
skb: report completion status for zero copy skbs
skb: api to report errors for zero copy skbs
tun: report orphan frags errors to zero copy callback
vhost-net: cleanup macros for DMA status tracking
vhost: track zero copy failures using DMA length
vhost: move -net
Zerocopy handling code is vhost-net specific.
Move it from vhost.c/vhost.h out to net.c
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 45
drivers/vhost/tcm_vhost.c | 1 +
drivers/vhost/vhost.c | 53
When tun transmits a zero copy skb, it orphans the frags
which might need to allocate extra memory, in atomic context.
If that fails, notify ubufs callback before freeing the skb
as a hint that device should disable zerocopy mode.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/net
It seems that to avoid deadlocks it is enough to poll vq before
we are going to use the last buffer. This is faster than
c70aa540c7a9f67add11ad3161096fb95233aa2e.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 14 --
1 file changed, 12 insertions(+), 2
for guest to guest
and guest to host traffic.
To fix this, suppress zero copy tx after a given number of
packets triggered late data copy. Re-enable periodically
to detect workload changes.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 61
such errors: this is used
by tun in case orphaning frags fails.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/skbuff.h | 1 +
net/core/skbuff.c | 20
2 files changed, 21 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index e5eae5b
this into account
and switch to copying in user context.
This patch updates all users but ignores the passed value for now:
it will be used by follow-up patches.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vhost.h | 2 +-
include/linux
Better document macros for DMA tracking. Add an
explicit one for DMA in progress instead of
relying on user supplying len != 1.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 3 ++-
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vhost.h | 12 +---
3 files
This will be used to disable zerocopy when error rate
is high.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/vhost.c | 7 ---
drivers/vhost/vhost.h | 4
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
On Mon, Sep 17, 2012 at 01:38:18PM -0300, Rafael Aquini wrote:
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
On Tue, Sep 18, 2012 at 01:24:21PM -0300, Rafael Aquini wrote:
+static inline void assign_balloon_mapping(struct page *page,
+ struct address_space *mapping)
+{
+ page-mapping = mapping;
+ smp_wmb();
+}
+
+static inline void
On Mon, Sep 17, 2012 at 03:15:31PM -0700, Andrew Morton wrote:
How can a patchset reach v10 and have zero Reviewed-by's?
I think the problem is, this adds an API between mm and balloon
device that is pretty complex: consider that previously we literally
only used alloc_page, __free_page and
On Mon, Oct 15, 2012 at 05:57:03PM +0800, Asias He wrote:
vhost-blk is an in-kernel virito-blk device accelerator.
Due to lack of proper in-kernel AIO interface, this version converts
guest's I/O request to bio and use submit_bio() to submit I/O directly.
So this version any supports raw
- this passed basic testing but
didn't measure performance yet.
virtio: align size for indirect buffers
Improve locality for indirect buffer allocations
and avoid false cache sharing by aligning
allocations to cache line size.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
On Wed, Oct 03, 2012 at 04:14:17PM +0930, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
Thinking about Sasha's patches, we can reduce ring usage
for virtio net small packets dramatically if we put
virtio net header inline with the data.
This can be done for free
On Thu, Oct 04, 2012 at 01:04:56PM +0930, Rusty Russell wrote:
Anthony Liguori anth...@codemonkey.ws writes:
Rusty Russell ru...@rustcorp.com.au writes:
Michael S. Tsirkin m...@redhat.com writes:
Thinking about Sasha's patches, we can reduce ring usage
for virtio net small packets
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Il 09/10/2012 06:59, Rusty Russell ha scritto:
Paolo Bonzini pbonz...@redhat.com writes:
Il 05/10/2012 07:43, Rusty Russell ha scritto:
That's good. But virtio_blk's scsi command is
for
guest to host and guest to guest both with and without zero copy tx.
Michael S. Tsirkin (8):
skb: report completion status for zero copy skbs
skb: api to report errors for zero copy skbs
tun: report orphan frags errors to zero copy callback
vhost-net: cleanup macros for DMA status tracking
1 - 100 of 9628 matches
Mail list logo
