All of lore.kernel.org
 help / color / mirror / Atom feed
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>
Subject: RE:(2) [Issue] timer callback registered with mod_timer is getting called beforetime
Date: Fri, 24 Sep 2021 19:34:43 +0530	[thread overview]
Message-ID: <1062227969.4242453.1632492283698@mail-kr5-0> (raw)
In-Reply-To: <20210924103812.GA142770@lothringen>

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]


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
 
 

[-- Attachment #2: rcptInfo.txt --]
[-- Type: application/octet-stream, Size: 1577 bytes --]


   =================================================================================================================================
      Subject    : Re: [Issue] timer callback registered with mod_timer is getting called beforetime
      From       : null
      Sent Date  : 2021-09-24 16:08  GMT+5:30
   =================================================================================================================================
                  Name                Type          Job Title                       Dept.                               Company                
   =================================================================================================================================
      Maninder Singh                 TO         Staff Engineer             System S/W Group /SRI-Delhi               Samsung Electronics 
      fweisbec@gmail.com             CC
      tglx@linutronix.de             CC
      mingo@kernel.org               CC
      linux-kernel@vger.kernel.org   CC
      Vaneet Narang                  CC         Staff Engineer             System S/W Group /SRI-Delhi               Samsung Electronics
      AMIT SAHRAWAT                  CC         Staff Engineer/Head o...   System S/W Group /SRI-Delhi               Samsung Electronics
      Chung-Ki Woo                   CC         Principal Engineer         S/W Platform R&D Lab.                     Samsung Electronics
   =================================================================================================================================

      parent reply	other threads:[~2021-09-24 14:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210924065310epcms5p69dd47a510faaa6bf68c243e02f2d0186@epcms5p6>
2021-09-24  6:53 ` [Issue] timer callback registered with mod_timer is getting called beforetime Maninder Singh
2021-09-24 10:38   ` Frederic Weisbecker
2021-09-24 12:08   ` Thomas Gleixner
     [not found]   ` <CGME20210924065310epcms5p69dd47a510faaa6bf68c243e02f2d0186@epcms5p2>
2021-09-24 14:04     ` Maninder Singh [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=1062227969.4242453.1632492283698@mail-kr5-0 \
    --to=maninder1.s@samsung.com \
    --cc=a.sahrawat@samsung.com \
    --cc=chungki0201.woo@samsung.com \
    --cc=frederic@kernel.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=v.narang@samsung.com \
    --cc=vishal.goel@samsung.com \
    /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.