Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1712422 > unrolled thread
| Started by | Will Deacon <will.deacon@arm.com> |
|---|---|
| First post | 2017-08-15 20:50 +0200 |
| Last post | 2017-09-06 13:30 +0200 |
| Articles | 5 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Will Deacon <will.deacon@arm.com> - 2017-08-15 20:50 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Vikram Mulukutla <markivx@codeaurora.org> - 2017-08-25 21:50 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Vikram Mulukutla <markivx@codeaurora.org> - 2017-08-25 22:30 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Vikram Mulukutla <markivx@codeaurora.org> - 2017-08-29 01:20 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync qiaozhou <qiaozhou@asrmicro.com> - 2017-09-06 13:30 +0200
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Date | 2017-08-15 20:50 +0200 |
| Subject | Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync |
| Message-ID | <ueP4C-4UD-11@gated-at.bofh.it> |
Hi Vikram, On Thu, Aug 03, 2017 at 04:25:12PM -0700, Vikram Mulukutla wrote: > On 2017-07-31 06:13, Will Deacon wrote: > >On Fri, Jul 28, 2017 at 12:09:38PM -0700, Vikram Mulukutla wrote: > >>On 2017-07-28 02:28, Will Deacon wrote: > >>>On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote: > > >>> > >>This does seem to help. Here's some data after 5 runs with and without > >>the > >>patch. > > > >Blimey, that does seem to make a difference. Shame it's so ugly! Would you > >be able to experiment with other values for CPU_RELAX_WFE_THRESHOLD? I had > >it set to 10000 in the diff I posted, but that might be higher than > >optimal. > >It would be interested to see if it correlates with num_possible_cpus() > >for the highly contended case. > > > >Will > > Sorry for the late response - I should hopefully have some more data with > different thresholds before the week is finished or on Monday. Did you get anywhere with the threshold heuristic? Will
[toc] | [next] | [standalone]
| From | Vikram Mulukutla <markivx@codeaurora.org> |
|---|---|
| Date | 2017-08-25 21:50 +0200 |
| Message-ID | <uisM9-8cd-17@gated-at.bofh.it> |
| In reply to | #1712422 |
Hi Will, On 2017-08-15 11:40, Will Deacon wrote: > Hi Vikram, > > On Thu, Aug 03, 2017 at 04:25:12PM -0700, Vikram Mulukutla wrote: >> On 2017-07-31 06:13, Will Deacon wrote: >> >On Fri, Jul 28, 2017 at 12:09:38PM -0700, Vikram Mulukutla wrote: >> >>On 2017-07-28 02:28, Will Deacon wrote: >> >>>On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote: >> >> >>> >> >>This does seem to help. Here's some data after 5 runs with and without >> >>the >> >>patch. >> > >> >Blimey, that does seem to make a difference. Shame it's so ugly! Would you >> >be able to experiment with other values for CPU_RELAX_WFE_THRESHOLD? I had >> >it set to 10000 in the diff I posted, but that might be higher than >> >optimal. >> >It would be interested to see if it correlates with num_possible_cpus() >> >for the highly contended case. >> > >> >Will >> >> Sorry for the late response - I should hopefully have some more data >> with >> different thresholds before the week is finished or on Monday. > > Did you get anywhere with the threshold heuristic? > > Will Here's some data from experiments that I finally got to today. I decided to recompile for every value of the threshold. Was doing a binary search of sorts and then started reducing by orders of magnitude. There pairs of rows here: Row1 is with cpu0 (little) at 300MHz and cpu4 at 1.9Ghz Row2 is with cpu0 (little) at 1.5GHz and cpu4 at 1.9Ghz It looks like even with the threshold set to 1, we don't hit the worst case of a single instance of locking taking a long time, probably a consequence of how the test is designed? However as we reduce the threshold, the fairness in terms of how many times each CPU acquires the lock skews towards the big CPU, starting with threshold=500 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? CPU_RELAX_WFE_THRESHOLD = 5000 and 2500 (very similar results) ===================================================== cpu0 time | cpu0 counter | cpu4 time | cpu4 counter | ==========|==============|===========|==============| 2|2763059|2|7323169 0|11477590|1|12110373 3|2762788|2|7329881 1|11557987|1|12042980 3|2765912|2|7308789 1|11470294|1|12120074 3|2761793|2|7333907 1|11431841|1|12155046 3|2762402|2|7328843 1|11495705|1|12096518 3|2764392|2|7308640 1|11479146|1|12111419 ====================================================| CPU_RELAX_WFE_THRESHOLD = 500 ===================================================== cpu0 time | cpu0 counter | cpu4 time | cpu4 counter | ==========|==============|===========|==============| 3|2338277|2|10052592 1|6963131|1|18103639 3|2337982|2|10037188 1|6979396|1|18082811 3|2337282|2|10052184 0|6954990|1|18109860 3|2338737|2|10039556 1|7185046|1|17809240 4|2338857|2|10027407 1|6958274|1|18111394 4|2340208|2|10031173 0|7097088|1|17921861 ----------------------------------------------------- ===================================================== CPU_RELAX_WFE_THRESHOLD = 50 ===================================================== cpu0 time | cpu0 counter | cpu4 time | cpu4 counter | ==========|==============|===========|==============| 4|1219792|2|18005180 0|1252767|1|25296935 4|1219312|2|18049566 1|1252625|1|25227292 4|1219884|2|18020775 1|1252363|1|25298387 4|1220862|2|18012062 1|1251827|1|25283787 4|1220489|2|18010055 0|1251729|1|25272917 3|1220088|2|18027279 0|1253264|1|25268834 ----------------------------------------------------- ===================================================== CPU_RELAX_WFE_THRESHOLD = 10 ===================================================== cpu0 time | cpu0 counter | cpu4 time | cpu4 counter | ==========|==============|===========|==============| 3|298604|1|23784805 0|293511|1|24604172 3|294707|2|23857487 0|292519|1|24564209 4|294199|1|23832180 0|293840|1|24593323 4|294314|1|23853353 0|293609|1|24635190 4|293802|1|23836764 0|293322|1|24553212 3|293658|1|23889801 0|292663|1|24552118 ----------------------------------------------------- ===================================================== CPU_RELAX_WFE_THRESHOLD = 5 ===================================================== cpu0 time | cpu0 counter | cpu4 time | cpu4 counter | ==========|==============|===========|==============| 3|173061|1|22332479 0|173759|1|23774009 3|174471|1|22342362 0|173161|1|23814466 3|173851|2|22235422 0|172734|1|23705848 2|173452|1|22255166 0|172830|1|23824301 2|173028|1|22390297 0|172336|1|23836407 3|172968|1|22285954 0|173207|1|23844900 ----------------------------------------------------- ===================================================== CPU_RELAX_WFE_THRESHOLD = 1 ===================================================== cpu0 time | cpu0 counter | cpu4 time | cpu4 counter | ==========|==============|===========|==============| 2|64245|1|6266848 0|77117|1|20917346 2|71310|1|5184106 1|77426|1|21040797 3|71335|2|5024650 0|77167|1|20934429 3|71295|1|5361696 0|77377|1|20902970 2|71357|1|5302482 0|77278|1|20967106 3|71158|1|5214564 0|77334|1|21022485 ----------------------------------------------------- ===================================================== Thanks, Vikram -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[toc] | [prev] | [next] | [standalone]
| From | Vikram Mulukutla <markivx@codeaurora.org> |
|---|---|
| Date | 2017-08-25 22:30 +0200 |
| Message-ID | <uitoS-ek-13@gated-at.bofh.it> |
| In reply to | #1720382 |
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
[toc] | [prev] | [next] | [standalone]
| From | Vikram Mulukutla <markivx@codeaurora.org> |
|---|---|
| Date | 2017-08-29 01:20 +0200 |
| Message-ID | <ujBu2-3iy-13@gated-at.bofh.it> |
| In reply to | #1720382 |
Hi Will,
On 2017-08-25 12:48, Vikram Mulukutla wrote:
> Hi Will,
>
> On 2017-08-15 11:40, Will Deacon wrote:
>> Hi Vikram,
>>
>> On Thu, Aug 03, 2017 at 04:25:12PM -0700, Vikram Mulukutla wrote:
>>> On 2017-07-31 06:13, Will Deacon wrote:
>>> >On Fri, Jul 28, 2017 at 12:09:38PM -0700, Vikram Mulukutla wrote:
>>> >>On 2017-07-28 02:28, Will Deacon wrote:
>>> >>>On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote:
>>>
>>> >>>
>>> >>This does seem to help. Here's some data after 5 runs with and without
>>> >>the
>>> >>patch.
>>> >
>>> >Blimey, that does seem to make a difference. Shame it's so ugly! Would you
>>> >be able to experiment with other values for CPU_RELAX_WFE_THRESHOLD? I had
>>> >it set to 10000 in the diff I posted, but that might be higher than
>>> >optimal.
>>> >It would be interested to see if it correlates with num_possible_cpus()
>>> >for the highly contended case.
>>> >
>>> >Will
>>>
>>> Sorry for the late response - I should hopefully have some more data
>>> with
>>> different thresholds before the week is finished or on Monday.
>>
>> Did you get anywhere with the threshold heuristic?
>>
>> Will
>
> Here's some data from experiments that I finally got to today. I
> decided
> to recompile for every value of the threshold. Was doing a binary
> search
> of sorts and then started reducing by orders of magnitude. There pairs
> of rows here:
>
Well here's something interesting. I tried a different platform and
found that
the workaround doesn't help much at all, similar to Qiao's observation
on his b.L
chipset. Something to do with the WFE implementation or event-stream?
I modified your patch to use a __delay(1) in place of the WFEs and this
was
the result (still with the 10k threshold). The worst-case lock time for
cpu0
drastically improves. Given that cpu0 re-enables interrupts between each
lock
attempt in my test case, I think the lock count matters less here.
cpu_relax() patch with WFEs (original workaround):
(pairs of rows, first row is with c0 at 300Mhz, second
with c0 at 1.9GHz. Both rows have cpu4 at 2.3GHz max time
is in microseconds)
------------------------------------------------------|
c0 max time| c0 lock count| c4 max time| c4 lock count|
------------------------------------------------------|
999843| 25| 2| 12988498| -> c0/cpu0 at
300Mhz
0| 8421132| 1| 9152979| -> c0/cpu0 at
1.9GHz
------------------------------------------------------|
999860| 160| 2| 12963487|
1| 8418492| 1| 9158001|
------------------------------------------------------|
999381| 734| 2| 12988636|
1| 8387562| 1| 9128056|
------------------------------------------------------|
989800| 750| 3| 12996473|
1| 8389091| 1| 9112444|
------------------------------------------------------|
cpu_relax() patch with __delay(1):
(pairs of rows, first row is with c0 at 300Mhz, second
with c0 at 1.9GHz. Both rows have cpu4 at 2.3GHz. max time
is in microseconds)
------------------------------------------------------|
c0 max time| c0 lock count| c4 max time| c4 lock count|
------------------------------------------------------|
7703| 1532| 2| 13035203| -> c0/cpu0 at
300Mhz
1| 8511686| 1| 8550411| -> c0/cpu0 at
1.9GHz
------------------------------------------------------|
7801| 1561| 2| 13040188|
1| 8553985| 1| 8609853|
------------------------------------------------------|
3953| 1576| 2| 13049991|
1| 8576370| 1| 8611533|
------------------------------------------------------|
3953| 1557| 2| 13030553|
1| 8509020| 1| 8543883|
------------------------------------------------------|
I should also note that my earlier kernel was 4.9-stable based
and the one above was on a 4.4-stable based kernel.
Thanks,
Vikram
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[toc] | [prev] | [next] | [standalone]
| From | qiaozhou <qiaozhou@asrmicro.com> |
|---|---|
| Date | 2017-09-06 13:30 +0200 |
| Message-ID | <umGGS-14f-5@gated-at.bofh.it> |
| In reply to | #1722049 |
On 2017年08月29日 07:12, Vikram Mulukutla wrote: > > Well here's something interesting. I tried a different platform and > found that > the workaround doesn't help much at all, similar to Qiao's observation > on his b.L > chipset. Something to do with the WFE implementation or event-stream? Hi Vikram, I did some experiments, to tune the ddr controller(and ddr ram) freq, and cci freq. And the result is as below: cpu2: a53, 832MHz, cpu7: a73, 1.75Hz cci: 832M dclk: DDR controller clock.(data rate = 4 * dclk) With cpu_relax bodging patch: ============================================================== dclk | cpu2 time | cpu2 counter | cpu7 time | cpu7 counter | =======|===========|==============|===========|==============| 78M | 8906| 55438| 13| 4015789| 156M | 5964| 75109| 4| 8229050| 500M | 102| 5984783| 1| 6400885| 600M | 16| 6233601| 1| 6504718| ============================================================== I suspect that the global exclusive monitor in ddr controller may play an important part. With ddr frequency is higher enough, it seems to handle the exclusive requests efficiently and fairly. If reducing cci freq to a lower value, the result of little core drops a lot again. cpu2: a53, 832MHz, cpu7: a73, 1.75Hz cci: 416M dclk: DDR controller clock.(data rate = 4 * dclk) With cpu_relax bodging patch: ============================================================== dclk | cpu2 time | cpu2 counter | cpu7 time | cpu7 counter | =======|===========|==============|===========|==============| 78M | 8837| 10596| 11| 3873635| 156M | 17597| 10211| 4| 6513493| 500M | 10888| 13214| 2| 8916396| 600M | 8934| 15842| 2| 9394124| ============================================================== I guess the result on your different platform might be related with DDR frequency too. Best Regards Qiao
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web