Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 24 Sep 2021 19:34:43 +0530
Message-ID: <1062227969.4242453.1632492283698@mail-kr5-0>
Mime-Version: 1.0
Subject: RE:(2) [Issue] timer callback registered with mod_timer is getting
 called beforetime
Reply-To: maninder1.s@samsung.com
Sender: Maninder Singh <maninder1.s@samsung.com>
From:   Maninder Singh <maninder1.s@samsung.com>
To:     Frederic Weisbecker <frederic@kernel.org>
CC:     "fweisbec@gmail.com" <fweisbec@gmail.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@kernel.org" <mingo@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Vaneet Narang <v.narang@samsung.com>,
        AMIT SAHRAWAT <a.sahrawat@samsung.com>,
        Chung-Ki Woo <chungki0201.woo@samsung.com>,
        Vishal Goel <vishal.goel@samsung.com>
In-Reply-To: <20210924103812.GA142770@lothringen>
Content-Type: multipart/mixed;
        boundary="----=_Part_4242452_2101301166.1632492283698"
CMS-TYPE: 105P
References: <20210924103812.GA142770@lothringen>
        <20210924065310epcms5p69dd47a510faaa6bf68c243e02f2d0186@epcms5p6>
        <CGME20210924065310epcms5p69dd47a510faaa6bf68c243e02f2d0186@epcms5p2>
Precedence: bulk

------=_Part_4242452_2101301166.1632492283698
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"


Hi Frederic,


> > Is it known behaviour for timers?
> > because only 1 CPU is assigned to update jiffies work to call do_timer utill unless it goes to idle state and pass ownership to other CPU.
> > 
> > we tried by making all CPU to handle code for jiffies updation (it will add performance hit)
> > but then no issue of abrupt jiffies change occured on system.
>  
> First of all, are you meeting this issue specifically on NOHZ_FULL? Because
> there is a pending fix for a related matter there:

No, this is not our case.

>  
>       https://lore.kernel.org/lkml/20210915142303.24297-1-frederic@kernel.org/
>  
> As for what you're reporting here, I think the core problem is the fact that the
> timekeeper (jiffies updater) is stuck with IRQs disabled for way too long. Even
> one millisecond is too much to tolerate. Do you have any idea about the source of
> that situation?
>  

Yes, definately interrupts should not be disabled for so long,
but sometimes there are 3rd party drivers/vendors module code can cause issue,
and it can be the same case and we are trying to reproduce issue again and check code path.

So we had 2 doubts:
(1) In this explained case timer callback will be called early right? 
(2) What if jiffies updation can be done by any of the CPU rather that making one
CPU owner? can it cause any side effectes? one we know is performance, there will be redundant calls
from other CPUs.

        /* Check, if the jiffies need an update */
        if (tick_do_timer_cpu == cpu)
                tick_do_update_jiffies64(now);


On our target, there is a race condition when irq_disable code path scheduled on same CPU
which is responsible for jiffies updation and in parallel CPU1 registers evet callback for 20/30 ms.
and due to abrupt jiffies change callback triggered within 1 ms of actual time, which cause actual
issue.

Thanks
Maninder Singh
 
 
------=_Part_4242452_2101301166.1632492283698
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="rcptInfo.txt"
Content-Transfer-Encoding: base64

DQogICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT0NCiAgICAgIFN1YmplY3QgICAgOiBSZTogW0lzc3VlXSB0aW1l
ciBjYWxsYmFjayByZWdpc3RlcmVkIHdpdGggbW9kX3RpbWVyIGlzIGdldHRpbmcgY2FsbGVkIGJl
Zm9yZXRpbWUNCiAgICAgIEZyb20gICAgICAgOiBudWxsDQogICAgICBTZW50IERhdGUgIDogMjAy
MS0wOS0yNCAxNjowOCAgR01UKzU6MzANCiAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgICAgICAgICAg
ICAgICAgTmFtZSAgICAgICAgICAgICAgICBUeXBlICAgICAgICAgIEpvYiBUaXRsZSAgICAgICAg
ICAgICAgICAgICAgICAgRGVwdC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29tcGFu
eSAgICAgICAgICAgICAgICANCiAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgICAgTWFuaW5kZXIgU2lu
Z2ggICAgICAgICAgICAgICAgIFRPICAgICAgICAgU3RhZmYgRW5naW5lZXIgICAgICAgICAgICAg
U3lzdGVtIFMvVyBHcm91cCAvU1JJLURlbGhpICAgICAgICAgICAgICAgU2Ftc3VuZ8KgRWxlY3Ry
b25pY3PCoA0KICAgICAgZndlaXNiZWNAZ21haWwuY29tICAgICAgICAgICAgIENDDQogICAgICB0
Z2x4QGxpbnV0cm9uaXguZGUgICAgICAgICAgICAgQ0MNCiAgICAgIG1pbmdvQGtlcm5lbC5vcmcg
ICAgICAgICAgICAgICBDQw0KICAgICAgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZyAgIEND
DQogICAgICBWYW5lZXQgTmFyYW5nICAgICAgICAgICAgICAgICAgQ0MgICAgICAgICBTdGFmZiBF
bmdpbmVlciAgICAgICAgICAgICBTeXN0ZW0gUy9XIEdyb3VwIC9TUkktRGVsaGkgICAgICAgICAg
ICAgICBTYW1zdW5nIEVsZWN0cm9uaWNzDQogICAgICBBTUlUIFNBSFJBV0FUICAgICAgICAgICAg
ICAgICAgQ0MgICAgICAgICBTdGFmZiBFbmdpbmVlci9IZWFkIG8uLi4gICBTeXN0ZW0gUy9XIEdy
b3VwIC9TUkktRGVsaGkgICAgICAgICAgICAgICBTYW1zdW5nwqBFbGVjdHJvbmljcw0KICAgICAg
Q2h1bmctS2kgV29vICAgICAgICAgICAgICAgICAgIENDICAgICAgICAgUHJpbmNpcGFsIEVuZ2lu
ZWVyICAgICAgICAgUy9XIFBsYXRmb3JtIFImRCBMYWIuICAgICAgICAgICAgICAgICAgICAgU2Ft
c3VuZyBFbGVjdHJvbmljcw0KICAgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo=

------=_Part_4242452_2101301166.1632492283698--