LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	tglx@linutronix.de
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	khilman@baylibre.com, linux-kernel@vger.kernel.org,
	fweisbec@gmail.com, arnd@arndb.de
Subject: Re: [PATCH] tick: prefer a lower rating device only if it's CPU local device
Date: Mon, 9 Jul 2018 16:12:29 +0100	[thread overview]
Message-ID: <299fd143-fc79-60de-40c7-fced7e9b3fb0@arm.com> (raw)
In-Reply-To: <CAFBinCBhBBK1TZnhH1bGrQP5SokaMNrk7C8OcMXaaTcR6_WOTg@mail.gmail.com>



On 08/07/18 21:59, Martin Blumenstingl wrote:
> Hi Thomas,
> 
> On Tue, Jul 3, 2018 at 6:48 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>> Hi Thomas,
>>
>> On Tue, Jul 03, 2018 at 06:08:19PM +0200, Thomas Gleixner wrote:
>>
>> [...]
>>
>>>>> / # cat /sys/devices/system/clockevents/broadcast/current_device
>>>>> meson6_tick
>>>>
>>>> OK, it can support broadcast
>>>>
>>>>> / # cat /sys/devices/system/clockevents/clockevent0/current_device
>>>>> dummy_timer
>>>>> / # cat /sys/devices/system/clockevents/clockevent1/current_device
>>>>> dummy_timer
>>>>> / # cat /sys/devices/system/clockevents/clockevent2/current_device
>>>>> dummy_timer
>>>>
>>>> But I can't understand why is dummy_timer the active event source and
>>>> not meson6_tick. And you say this is working case ? Looks suspicious.
>>>
>>> Because if it switches to broadcast mode then the meson timer cannot longer
>>> be used as per cpu timer. It's broadcasting to all CPUs via the dummy timer.
>>
>> Thanks for the explanation. I completely misread the sysfs entry and
>> assume clockevent_register failed for meson6 and hence regarded as
>> suspicious which is complete non-sense, my bad. Sorry for that.
>> I think I now understand the issue.
>>
>> 1. Juno usecase for which $subject was added as fix:
>>
>> Two system wide timers(cpumask=possible cpus) with rating 300 and 400.
>> When second one with 400 is added, timer with rating 300 is added to
>> released list and again added back to main one. In this case both were
>> chosen as preferred and that resulted in deadlock.
>>
>> 2. Meson6 usecase:
>>
>> When meson6_tick is added, it's set as preferred and dummy_timer is released.
>> When it's being added back from the released list, it will be chosen as
>> preferred as it's per_cpu resulting in deadlock.
>>
>> I am not sure how to fix this. Should the fix to my original problem have
>> checks for both old and new for per-cpu  to prevent the issue reported on
>> Meson6
> could you please answer Sudeep's question?
> 

OK, I think I have misunderstood my original problem because of the
cpumask_equal for nr_bits <= BITS_PER_LONG. It uses nr_cpumask_bits
which is NR_CPUS when CPUMASK_OFFSTACK is not enabled.

Enabling it fixes my original problem(reverting $subject patch). So it
should be reverted. And also pointed out the issue with ARM mem timer.

I am sorry for the mess, I will post the revert and along with the fix
to my issue. Once again sorry for not understanding the root cause
correctly.
-- 
Regards,
Sudeep

      reply	other threads:[~2018-07-09 15:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 16:02 Sudeep Holla
2018-05-13 13:09 ` [tip:timers/core] tick: Prefer " tip-bot for Sudeep Holla
2018-07-02 23:44 ` [PATCH] tick: prefer " Kevin Hilman
2018-07-03 10:53   ` Sudeep Holla
2018-07-03 15:04     ` Kevin Hilman
2018-07-03 15:44       ` Sudeep Holla
2018-07-03 16:08         ` Thomas Gleixner
2018-07-03 16:48           ` Sudeep Holla
2018-07-08 20:59             ` Martin Blumenstingl
2018-07-09 15:12               ` Sudeep Holla [this message]

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=299fd143-fc79-60de-40c7-fced7e9b3fb0@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=arnd@arndb.de \
    --cc=fweisbec@gmail.com \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH] tick: prefer a lower rating device only if it'\''s CPU local device' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).