If we reset the virtio-blk device before the requests already dispatched
to the virtio-blk driver from the block layer are finised, we will stuck
in blk_cleanup_queue() and the remove will fail.
blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued
before DEAD marking. However i
On Thu, May 03, 2012 at 07:51:18AM +0200, Sasha Levin wrote:
> On Thu, May 3, 2012 at 7:29 AM, Michael S. Tsirkin wrote:
> > Sasha, didn't you have a patch to allocate
> > things using cache in virtio core?
> > What happened to it?
> >
> > Thanks,
> > MST
>
> It got stuck due to several things, a
On 05/03/2012 01:02 PM, Sasha Levin wrote:
On Thu, May 3, 2012 at 4:19 AM, Asias He wrote:
@@ -190,6 +194,7 @@ static void do_virtblk_request(struct request_queue *q)
while ((req = blk_peek_request(q)) != NULL) {
BUG_ON(req->nr_phys_segments + 2> vblk->sg_elems);
+
On 05/03/2012 01:27 PM, Michael S. Tsirkin wrote:
On Thu, May 03, 2012 at 10:19:52AM +0800, Asias He wrote:
If we reset the virtio-blk device before the requests already dispatched
to the virtio-blk driver from the block layer are finised, we will stuck
in blk_cleanup_queue() and the remove will
On Thu, May 03, 2012 at 03:30:47PM +0800, Asias He wrote:
> If we reset the virtio-blk device before the requests already dispatched
> to the virtio-blk driver from the block layer are finised, we will stuck
> in blk_cleanup_queue() and the remove will fail.
>
> blk_cleanup_queue() calls blk_drain
On 27.04.2012, at 07:43, Benjamin Herrenschmidt wrote:
> This is necessary for qemu to be able to pass the right information
> to the guest, such as the supported page sizes and corresponding
> encodings in the SLB and hash table, which can vary depending
> on the processor type, the type of KVM
This patch is for showing what I am thinking and only compile tested
on linux-next, so an RFC.
Although I might misread something, I am not sure whether every user of
this API wanted to avoid contention check without CONFIG_PREEMPT.
Any comments will be appreciated.
Thanks,
Takuya
===
F
Hi,
During reading the vhost-net code, I find the following,
static void handle_tx(struct vhost_net *net)
{
struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
unsigned out, in, s;
int head;
struct msghdr msg = {
.msg_name = NULL,
On Thu, 2012-05-03 at 17:12 +0900, Takuya Yoshikawa wrote:
>
> Although we can do that using spin_is_contended() and cond_resched(),
> changing cond_resched_lock() to satisfy such a need is another option.
>
Yeah, not a pretty patch. Changing all cond_resched_lock() sites just to
change one and i
If vcpu executes hlt instruction while async PF is waiting to be delivered
vcpu can block and deliver async PF only after another even wakes it
up. This happens because kvm_check_async_pf_completion() will remove
completion event from vcpu->async_pf.done before entering kvm_vcpu_block()
and this wi
On Thu, May 3, 2012 at 9:32 AM, Michael S. Tsirkin wrote:
> On Thu, May 03, 2012 at 07:51:18AM +0200, Sasha Levin wrote:
>> On Thu, May 3, 2012 at 7:29 AM, Michael S. Tsirkin wrote:
>> > Sasha, didn't you have a patch to allocate
>> > things using cache in virtio core?
>> > What happened to it?
>
On Thu, May 03, 2012 at 04:33:55PM +0800, Liu ping fan wrote:
> Hi,
>
> During reading the vhost-net code, I find the following,
>
> static void handle_tx(struct vhost_net *net)
> {
> struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
> unsigned out, in, s;
> int head;
On Thu, May 03, 2012 at 10:38:56AM +0200, Sasha Levin wrote:
> On Thu, May 3, 2012 at 9:32 AM, Michael S. Tsirkin wrote:
> > On Thu, May 03, 2012 at 07:51:18AM +0200, Sasha Levin wrote:
> >> On Thu, May 3, 2012 at 7:29 AM, Michael S. Tsirkin wrote:
> >> > Sasha, didn't you have a patch to allocat
On Thu, May 3, 2012 at 10:44 AM, Michael S. Tsirkin wrote:
> On Thu, May 03, 2012 at 10:38:56AM +0200, Sasha Levin wrote:
>> On Thu, May 3, 2012 at 9:32 AM, Michael S. Tsirkin wrote:
>> > On Thu, May 03, 2012 at 07:51:18AM +0200, Sasha Levin wrote:
>> >> On Thu, May 3, 2012 at 7:29 AM, Michael S.
On Thu, May 03, 2012 at 10:48:53AM +0200, Sasha Levin wrote:
> On Thu, May 3, 2012 at 10:44 AM, Michael S. Tsirkin wrote:
> > On Thu, May 03, 2012 at 10:38:56AM +0200, Sasha Levin wrote:
> >> On Thu, May 3, 2012 at 9:32 AM, Michael S. Tsirkin wrote:
> >> > On Thu, May 03, 2012 at 07:51:18AM +0200
Oh, got it. It is a very interesting implement.
Thanks and regards,
pingfan
On Thu, May 3, 2012 at 4:41 PM, Michael S. Tsirkin wrote:
> On Thu, May 03, 2012 at 04:33:55PM +0800, Liu ping fan wrote:
>> Hi,
>>
>> During reading the vhost-net code, I find the following,
>>
>> static void handle_tx(
On (Wed) 04 Apr 2012 [12:19:55], Michael S. Tsirkin wrote:
> disable_cb is just an optimization: it
> can not guarantee that there are no callbacks.
Even then, what's the harm in keeping it? If indeed there's an
attempt to raise an interrupt after the host has been notified, it
will be suppressed
On Thu, May 03, 2012 at 04:29:59PM +0530, Amit Shah wrote:
> On (Wed) 04 Apr 2012 [12:19:55], Michael S. Tsirkin wrote:
> > disable_cb is just an optimization: it
> > can not guarantee that there are no callbacks.
>
> Even then, what's the harm in keeping it? If indeed there's an
> attempt to rai
Currently we flush the TLB while holding mmu_lock. This
increases the lock hold time by the IPI round-trip time, increasing
contention, and makes dropping the lock (for latency reasons) harder.
This patch changes TLB management to be usable locklessly, introducing
the following APIs:
kvm_mark_
Signed-off-by: Avi Kivity
---
virt/kvm/kvm_main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 643ce01..9e2db44 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -302,11 +302,11 @@ static void kv
Signed-off-by: Avi Kivity
---
arch/x86/kvm/mmu.c |8 ++--
virt/kvm/kvm_main.c |2 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 0e7bcff..bc1d83c 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1138,7 +1138
This patchset implements unlocked TLB flushing for KVM. An operation that
generates stale TLB entries can mark the TLB as dirty instead of flushing
immediately, and then flush after releasing mmu_lock but before returning
to the guest or the caller. A few call sites are converted too.
Note not a
mmu_page_zap_pte() is modified to mark the TLB as dirty; but currently
only FNAME(invlpg) takes advantage of this.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/mmu.c |7 +++
arch/x86/kvm/paging_tmpl.h |5 +++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch
On 05/03/2012 05:07 AM, Marcelo Tosatti wrote:
>> 'entry' is not a problem since it is from atomically read-write as
>> mentioned above, i need change this code to:
>>
>> /*
>> * Optimization: for pte sync, if spte was writable the hash
>> * lookup is unne
On 05/03/2012 05:10 AM, Marcelo Tosatti wrote:
> On Wed, May 02, 2012 at 01:39:51PM +0800, Xiao Guangrong wrote:
>> On 04/29/2012 04:50 PM, Takuya Yoshikawa wrote:
>>
>>> On Fri, 27 Apr 2012 11:52:13 -0300
>>> Marcelo Tosatti wrote:
>>>
Yes but the objective you are aiming for is to read and
On 05/03/2012 03:09 PM, Xiao Guangrong wrote:
> Actually, the improvement of lockless is that it can let vcpu to be parallel
> as possible.
>
> From the test result, lockless gains little improvement for unix-migration,
> in this case, the vcpus are almost idle (at least not busy).
>
> The large im
On Thu, 03 May 2012 10:35:27 +0200
Peter Zijlstra wrote:
> On Thu, 2012-05-03 at 17:12 +0900, Takuya Yoshikawa wrote:
> >
> > Although we can do that using spin_is_contended() and cond_resched(),
> > changing cond_resched_lock() to satisfy such a need is another option.
> >
> Yeah, not a pretty
On 05/03/2012 08:15 AM, Takuya Yoshikawa wrote:
> On Wed, 02 May 2012 13:39:51 +0800
> Xiao Guangrong wrote:
>
>>> Was the problem really mmu_lock contention?
>
>> Takuya, i am so tired to argue the advantage of lockless write-protect
>> and lockless O(1) dirty-log again and again.
>
> You are
On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote:
> Although the real use case is out of this RFC patch, we are now discussing
> a case in which we may hold a spin_lock for long time, ms order, depending
> on workload; and in that case, other threads -- VCPU threads -- should be
> given h
On Thu, 03 May 2012 20:23:18 +0800
Xiao Guangrong wrote:
> Takuya, i am sorry, please forgive my rudeness! Since my English is
> so poor that it is easy for me to misunderstand the mail. :(
Me too, I am not good at reading/speaking English!
No problem.
> > But this is your work and it's up to y
On 05/03/2012 03:29 PM, Peter Zijlstra wrote:
> On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote:
> > Although the real use case is out of this RFC patch, we are now discussing
> > a case in which we may hold a spin_lock for long time, ms order, depending
> > on workload; and in that case
On Thu, 03 May 2012 14:29:10 +0200
Peter Zijlstra wrote:
> On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote:
> > Although the real use case is out of this RFC patch, we are now discussing
> > a case in which we may hold a spin_lock for long time, ms order, depending
> > on workload; and
On 05/03/2012 07:22 PM, Avi Kivity wrote:
> Currently we flush the TLB while holding mmu_lock. This
> increases the lock hold time by the IPI round-trip time, increasing
> contention, and makes dropping the lock (for latency reasons) harder.
>
> This patch changes TLB management to be usable loc
On Tue, 1 May 2012, Jeremy Fitzhardinge wrote:
> On 05/01/2012 03:59 AM, Peter Zijlstra wrote:
> > On Tue, 2012-05-01 at 12:57 +0200, Peter Zijlstra wrote:
> >> Anyway, I don't have any idea about the costs involved with
> >> HAVE_RCU_TABLE_FREE, but I don't think its much.. otherwise these other
>
On Thu, 03 May 2012 15:47:26 +0300
Avi Kivity wrote:
> On 05/03/2012 03:29 PM, Peter Zijlstra wrote:
> > On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote:
> > > Although the real use case is out of this RFC patch, we are now discussing
> > > a case in which we may hold a spin_lock for lo
On 05/03/2012 04:23 PM, Xiao Guangrong wrote:
> On 05/03/2012 07:22 PM, Avi Kivity wrote:
>
> > Currently we flush the TLB while holding mmu_lock. This
> > increases the lock hold time by the IPI round-trip time, increasing
> > contention, and makes dropping the lock (for latency reasons) harder.
On 05/03/2012 05:11 PM, Takuya Yoshikawa wrote:
> On Thu, 03 May 2012 15:47:26 +0300
> Avi Kivity wrote:
>
> > On 05/03/2012 03:29 PM, Peter Zijlstra wrote:
> > > On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote:
> > > > Although the real use case is out of this RFC patch, we are now
> >
On 05/03/2012 05:27 PM, Avi Kivity wrote:
> On 05/03/2012 05:11 PM, Takuya Yoshikawa wrote:
> > On Thu, 03 May 2012 15:47:26 +0300
> > Avi Kivity wrote:
> >
> > > On 05/03/2012 03:29 PM, Peter Zijlstra wrote:
> > > > On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote:
> > > > > Although the
On Thu, 2012-05-03 at 22:00 +0900, Takuya Yoshikawa wrote:
> But as I could not see why spin_needbreak() was differently
> implemented
> depending on CONFIG_PREEMPT, I wanted to understand the meaning.
Its been that way since before voluntary preemption was introduced, so
its possible Ingo simply
Hello,
3.4-rc5
[32881.212463] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly.
Using workaround
[32882.360505]
[32882.360509] ==
[32882.360511] [ INFO: possible circular locking dependency detected ]
[32882.360515] 3.4.0-rc5-dbg-
On 05/03/2012 09:00 PM, Takuya Yoshikawa wrote:
> On Thu, 03 May 2012 14:29:10 +0200
> Peter Zijlstra wrote:
>
>> On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote:
>>> Although the real use case is out of this RFC patch, we are now discussing
>>> a case in which we may hold a spin_lock
On Wed, 02 May 2012 12:20:40 +0200, Peter Zijlstra wrote:
[...]
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index f96a5b5..8ca33e9 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -19,6 +19,8 @@
> #include
> #include
>
> +static inli
42 matches
Mail list logo
