From: Paul Mackerras <paulus@ozlabs.org>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: kvm-ppc@vger.kernel.org,
PowerPC email list <linuxppc-dev@lists.ozlabs.org>,
agraf@suse.com, Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Boqun Feng <boqun.feng@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 2/2] KVM: PPC: Don't take lock when check irq's resend flag
Date: Mon, 20 Jun 2016 05:27:17 +0000 [thread overview]
Message-ID: <20160620052717.GC29366@fergus.ozlabs.ibm.com> (raw)
In-Reply-To: <1463382133.19947.10.camel@TP420>
On Mon, May 16, 2016 at 03:02:13PM +0800, Li Zhong wrote:
> It seems that we don't need to take the lock before evaluating irq's
> resend flag. What needed is to make sure when we clear the ics's bit
> in the icp's resend_map, we don't miss the resend flag of the irqs
> that set the bit.
>
> And seems this could be ordered through the barrier in test_and_clear_bit(),
> and an newly added wmb when setting irq's resend flag, and icp's resend_map.
This looks fine to me. Is there a measurable performance improvement
from this? I understand it could be hard to measure.
Also, you could make the patch description more definite - just say
that we don't need to take the lock, there's no need for "seems".
Paul.
WARNING: multiple messages have this Message-ID (diff)
From: Paul Mackerras <paulus@ozlabs.org>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: kvm-ppc@vger.kernel.org,
PowerPC email list <linuxppc-dev@lists.ozlabs.org>,
agraf@suse.com, Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Boqun Feng <boqun.feng@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 2/2] KVM: PPC: Don't take lock when check irq's resend flag
Date: Mon, 20 Jun 2016 15:27:17 +1000 [thread overview]
Message-ID: <20160620052717.GC29366@fergus.ozlabs.ibm.com> (raw)
In-Reply-To: <1463382133.19947.10.camel@TP420>
On Mon, May 16, 2016 at 03:02:13PM +0800, Li Zhong wrote:
> It seems that we don't need to take the lock before evaluating irq's
> resend flag. What needed is to make sure when we clear the ics's bit
> in the icp's resend_map, we don't miss the resend flag of the irqs
> that set the bit.
>
> And seems this could be ordered through the barrier in test_and_clear_bit(),
> and an newly added wmb when setting irq's resend flag, and icp's resend_map.
This looks fine to me. Is there a measurable performance improvement
from this? I understand it could be hard to measure.
Also, you could make the patch description more definite - just say
that we don't need to take the lock, there's no need for "seems".
Paul.
next prev parent reply other threads:[~2016-06-20 5:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 6:58 [RFC PATCH 1/2] KVM: PPC: divide the ics lock into smaller ones for each irq Li Zhong
2016-05-16 6:58 ` Li Zhong
2016-05-16 7:02 ` [RFC PATCH 2/2] KVM: PPC: Don't take lock when check irq's resend flag Li Zhong
2016-05-16 7:02 ` Li Zhong
2016-06-20 5:27 ` Paul Mackerras [this message]
2016-06-20 5:27 ` Paul Mackerras
2016-06-21 2:57 ` Li Zhong
2016-06-21 2:57 ` Li Zhong
2016-06-20 5:25 ` [RFC PATCH 1/2] KVM: PPC: divide the ics lock into smaller ones for each irq Paul Mackerras
2016-06-20 5:25 ` Paul Mackerras
2016-06-21 2:47 ` Li Zhong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160620052717.GC29366@fergus.ozlabs.ibm.com \
--to=paulus@ozlabs.org \
--cc=agraf@suse.com \
--cc=benh@kernel.crashing.org \
--cc=boqun.feng@linux.vnet.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=zhong@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.