From: yangyingliang@huawei.com (Yang Yingliang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] irqchip/gic-v3-its: handle rd_idx wrapping in its_wait_for_range_completion()
Date: Thu, 1 Mar 2018 09:53:51 +0800 [thread overview]
Message-ID: <5A975D2F.1010302@huawei.com> (raw)
In-Reply-To: <866073z7pr.wl-marc.zyngier@arm.com>
On 2018/2/12 2:45, Marc Zyngier wrote:
Hi, Marc
Sorry for replying so late.
> On Sun, 11 Feb 2018 03:42:01 +0000,
> Yang Yingliang wrote:
>
> Hi Yang,
>
>> In direct case, rd_idx will wrap if other cpus post commands
>> that make rd_idx increase. When rd_idx wrapped, the driver prints
>> timeout messages but in fact the command is finished. To handle
>> this case by adding last_rd_id to check rd_idx whether wrapped.
>>
>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> Please always Cc LKML on irqchip related patches.
>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 84 ++++++++++++++++++++++------------------
>> 1 file changed, 46 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 06f025f..d7176d1 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -713,7 +713,8 @@ static void its_flush_cmd(struct its_node *its, struct its_cmd_block *cmd)
>>
>> static int its_wait_for_range_completion(struct its_node *its,
>> struct its_cmd_block *from,
>> - struct its_cmd_block *to)
>> + struct its_cmd_block *to,
>> + u64 last_rd_idx)
>> {
>> u64 rd_idx, from_idx, to_idx;
>> u32 count = 1000000; /* 1s! */
>> @@ -724,9 +725,14 @@ static int its_wait_for_range_completion(struct its_node *its,
>> while (1) {
>> rd_idx = readl_relaxed(its->base + GITS_CREADR);
>>
>> - /* Direct case */
>> - if (from_idx < to_idx && rd_idx >= to_idx)
>> - break;
>> +
>> + /*
>> + * Direct case. In this case, rd_idx may wrapped,
>> + * because other cpus may post commands that make
>> + * rd_idx increase.
>> + */
>> + if (from_idx < to_idx && (rd_idx >= to_idx || rd_idx < last_rd_idx))
>> + break;
>>
>> /* Wrapped case */
>> if (from_idx >= to_idx && rd_idx >= to_idx && rd_idx < from_idx)
>> @@ -746,40 +752,42 @@ static int its_wait_for_range_completion(struct its_node *its,
> [...]
>
>> + last_rd_idx = readl_relaxed(its->base + GITS_CREADR); \
> What is this last_rd_idx exactly? It is just some random sampling of
> the read pointer after we've posted our commands. It can still be in
> any position. And if the reader as wrapped because other CPUs are
> feeding more commands to the queue, it could just as well overtake
> last_rd_idx, making your new condition just as false. Yes, this is
> unlikely, but still.
>
> If you're going to harden the command queue wrapping, I'd suggest you
> implement a generation mechanism so that we can easily work out if
> we've seen the queue wrapping or not. THis would lift any kind of
> ambiguity once and for all.
I get a lot of timeout messages, when I am doing set affinity stress
testing which
will post many its commands. I will try another way to handle the
wrapped case.
Regards,
Yang
>
> Thanks,
>
> M.
>
WARNING: multiple messages have this Message-ID (diff)
From: Yang Yingliang <yangyingliang@huawei.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] irqchip/gic-v3-its: handle rd_idx wrapping in its_wait_for_range_completion()
Date: Thu, 1 Mar 2018 09:53:51 +0800 [thread overview]
Message-ID: <5A975D2F.1010302@huawei.com> (raw)
In-Reply-To: <866073z7pr.wl-marc.zyngier@arm.com>
On 2018/2/12 2:45, Marc Zyngier wrote:
Hi, Marc
Sorry for replying so late.
> On Sun, 11 Feb 2018 03:42:01 +0000,
> Yang Yingliang wrote:
>
> Hi Yang,
>
>> In direct case, rd_idx will wrap if other cpus post commands
>> that make rd_idx increase. When rd_idx wrapped, the driver prints
>> timeout messages but in fact the command is finished. To handle
>> this case by adding last_rd_id to check rd_idx whether wrapped.
>>
>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> Please always Cc LKML on irqchip related patches.
>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 84 ++++++++++++++++++++++------------------
>> 1 file changed, 46 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 06f025f..d7176d1 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -713,7 +713,8 @@ static void its_flush_cmd(struct its_node *its, struct its_cmd_block *cmd)
>>
>> static int its_wait_for_range_completion(struct its_node *its,
>> struct its_cmd_block *from,
>> - struct its_cmd_block *to)
>> + struct its_cmd_block *to,
>> + u64 last_rd_idx)
>> {
>> u64 rd_idx, from_idx, to_idx;
>> u32 count = 1000000; /* 1s! */
>> @@ -724,9 +725,14 @@ static int its_wait_for_range_completion(struct its_node *its,
>> while (1) {
>> rd_idx = readl_relaxed(its->base + GITS_CREADR);
>>
>> - /* Direct case */
>> - if (from_idx < to_idx && rd_idx >= to_idx)
>> - break;
>> +
>> + /*
>> + * Direct case. In this case, rd_idx may wrapped,
>> + * because other cpus may post commands that make
>> + * rd_idx increase.
>> + */
>> + if (from_idx < to_idx && (rd_idx >= to_idx || rd_idx < last_rd_idx))
>> + break;
>>
>> /* Wrapped case */
>> if (from_idx >= to_idx && rd_idx >= to_idx && rd_idx < from_idx)
>> @@ -746,40 +752,42 @@ static int its_wait_for_range_completion(struct its_node *its,
> [...]
>
>> + last_rd_idx = readl_relaxed(its->base + GITS_CREADR); \
> What is this last_rd_idx exactly? It is just some random sampling of
> the read pointer after we've posted our commands. It can still be in
> any position. And if the reader as wrapped because other CPUs are
> feeding more commands to the queue, it could just as well overtake
> last_rd_idx, making your new condition just as false. Yes, this is
> unlikely, but still.
>
> If you're going to harden the command queue wrapping, I'd suggest you
> implement a generation mechanism so that we can easily work out if
> we've seen the queue wrapping or not. THis would lift any kind of
> ambiguity once and for all.
I get a lot of timeout messages, when I am doing set affinity stress
testing which
will post many its commands. I will try another way to handle the
wrapped case.
Regards,
Yang
>
> Thanks,
>
> M.
>
next prev parent reply other threads:[~2018-03-01 1:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-11 3:42 [PATCH] irqchip/gic-v3-its: handle rd_idx wrapping in its_wait_for_range_completion() Yang Yingliang
2018-02-11 18:45 ` Marc Zyngier
2018-02-11 18:45 ` Marc Zyngier
2018-03-01 1:53 ` Yang Yingliang [this message]
2018-03-01 1:53 ` Yang Yingliang
2018-03-06 7:06 ` [RFC PATCH] irqchip/gic-v3-its: handle wrapped case " Yang Yingliang
2018-03-06 7:06 ` Yang Yingliang
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=5A975D2F.1010302@huawei.com \
--to=yangyingliang@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.