[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fd24e530d09f31656e6df4c6ecbbb6e0@codeaurora.org>
Date: Fri, 25 Aug 2017 13:25:42 -0700
From: Vikram Mulukutla <markivx@...eaurora.org>
To: Will Deacon <will.deacon@....com>
Cc: qiaozhou <qiaozhou@...micro.com>,
Thomas Gleixner <tglx@...utronix.de>,
John Stultz <john.stultz@...aro.org>, sboyd@...eaurora.org,
LKML <linux-kernel@...r.kernel.org>,
Wang Wilbur <wilburwang@...micro.com>,
Marc Zyngier <marc.zyngier@....com>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel-owner@...r.kernel.org, sudeep.holla@....com
Subject: Re: [Question]: try to fix contention between expire_timers and
try_to_del_timer_sync
On 2017-08-25 12:48, Vikram Mulukutla wrote:
>
> If I understand the code correctly, the upper 32 bits of an ARM64
> virtual
> address will overflow when 1 is added to it, and so we'll keep WFE'ing
> on
> every subsequent cpu_relax invoked from the same PC, until we cross the
> hard-coded threshold, right?
>
Oops, misread that. Second time we enter cpu_relax from the same PC, we
do a WFE. Then we stop doing the WFE until we hit the threshold using
the
per-cpu counter. So with a higher threshold, we wait for more
cpu_relax()
calls before starting the WFE again.
So a lower threshold implies we should hit WFE branch sooner. It seems
that since my test keeps the while loop going for a full 5 seconds, a
lower
threshold will obviously result in more WFEs and lower the
lock-acquired-count.
I guess we want a high threshold but not so high that the little CPU has
to wait a while before the big CPU counts up to the threshold, is that
correct?
Thanks,
Vikram
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Powered by blists - more mailing lists