From: Jason Gunthorpe <jgg@ziepe.ca>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
John Stultz <john.stultz@linaro.org>,
Prarit Bhargava <prarit@redhat.com>
Subject: Re: [PATCH] rtc: adapt allowed RTC update error
Date: Tue, 1 Dec 2020 13:35:40 -0400 [thread overview]
Message-ID: <20201201173540.GH5487@ziepe.ca> (raw)
In-Reply-To: <20201201171420.GN1900232@localhost>
On Tue, Dec 01, 2020 at 06:14:20PM +0100, Miroslav Lichvar wrote:
> On Tue, Dec 01, 2020 at 12:12:24PM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 01, 2020 at 03:38:35PM +0100, Miroslav Lichvar wrote:
> > > + unsigned long time_set_nsec_fuzz;
> > > + static unsigned int attempt;
> >
> > Adding a static value instide a static inline should not be done
>
> Well, grepping through the other header files in include/linux, this
> would not be the first case.
Nevertheless, it should be avoided and has surprising behaviors.
> > I'm not sure using a static like this is the best idea anyhow, if you
> > want something like this it should be per-rtc, not global
>
> If there are multiple RTCs, are they all updated in this 11-minute
> sync?
Yes, but they have different offsets and thus different timers,
IIRC. Though only one gets to be the CONFIG_RTC_SYSTOHC_DEVICE
If you are going to put some static it is clearer to put it along side
the sync_rtc_clock()
> I found no good explanation. It seems to depend on what system is
> doing, if it's idle, etc. I suspect it's a property of the workqueues
> that they cannot generally guarantee the jobs to run exactly on time.
> I tried switching to the non-power-efficient and high priority
> workqueues and it didn't seem to make a big difference.
When I wrote it originally the workqueues got increasingly inaccurate
the longer the duration, so it does a very short sleep to get back on
track.
If you are missing that time target it must be constantly scheduling
new delayed work and none of it hits the target for long, long time
periods? This seems like a more fundamental problem someplace else in
the kernel.
Jason
next prev parent reply other threads:[~2020-12-01 17:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 14:38 [PATCH] rtc: adapt allowed RTC update error Miroslav Lichvar
2020-12-01 16:12 ` Jason Gunthorpe
2020-12-01 17:14 ` Miroslav Lichvar
2020-12-01 17:35 ` Jason Gunthorpe [this message]
2020-12-02 10:01 ` [PATCHv2] " Miroslav Lichvar
2020-12-02 13:44 ` [PATCH] " Thomas Gleixner
2020-12-02 15:07 ` Miroslav Lichvar
2020-12-02 15:36 ` Miroslav Lichvar
2020-12-02 18:36 ` Thomas Gleixner
2020-12-02 16:27 ` Jason Gunthorpe
2020-12-02 19:21 ` Thomas Gleixner
2020-12-02 20:54 ` Jason Gunthorpe
2020-12-02 22:08 ` Thomas Gleixner
2020-12-02 23:03 ` Jason Gunthorpe
2020-12-03 1:14 ` Thomas Gleixner
2020-12-03 2:04 ` Jason Gunthorpe
2020-12-03 2:10 ` Alexandre Belloni
2020-12-03 15:39 ` Thomas Gleixner
2020-12-03 16:16 ` Jason Gunthorpe
2020-12-03 21:05 ` Thomas Gleixner
2020-12-03 21:31 ` Thomas Gleixner
2020-12-03 22:36 ` Jason Gunthorpe
2020-12-04 13:02 ` Thomas Gleixner
2020-12-04 14:08 ` Jason Gunthorpe
2020-12-04 14:37 ` Alexandre Belloni
2020-12-04 14:46 ` Jason Gunthorpe
2020-12-04 15:08 ` Alexandre Belloni
2020-12-04 15:57 ` Jason Gunthorpe
2020-12-04 16:35 ` Alexandre Belloni
2020-12-03 22:00 ` Alexandre Belloni
2020-12-04 9:34 ` Thomas Gleixner
2020-12-04 9:51 ` Alexandre Belloni
2020-12-04 10:44 ` Thomas Gleixner
2020-12-03 17:29 ` Alexandre Belloni
2020-12-03 19:52 ` Thomas Gleixner
2020-12-03 15:52 ` Jason Gunthorpe
2020-12-03 16:07 ` Alexandre Belloni
2020-12-03 20:10 ` Jason Gunthorpe
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=20201201173540.GH5487@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlichvar@redhat.com \
--cc=prarit@redhat.com \
--cc=tglx@linutronix.de \
/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 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).