On 2020-12-11 15:36:27 [+0100], Thomas Gleixner wrote:
> So the change at hand does not make things worse, right?
Correct. This *ping*-*pong* was there before this patch because
->running_timer is always cleared after the callback finishes.
I was just curious why out of a sudden there are *that*
On Tue, Dec 08 2020 at 09:50, Sebastian Andrzej Siewior wrote:
> On 2020-12-07 08:06:48 [-0800], Paul E. McKenney wrote:
>> > Yes, but it triggers frequently. Like `rcuc' is somehow is aligned with
>> > the timeout.
>>
>> Given that a lot of RCU processing is event-driven based on timers,
>> and g
On Tue, Dec 08, 2020 at 09:50:49AM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-12-07 08:06:48 [-0800], Paul E. McKenney wrote:
> > > Yes, but it triggers frequently. Like `rcuc' is somehow is aligned with
> > > the timeout.
> >
> > Given that a lot of RCU processing is event-driven based on
On 2020-12-07 08:06:48 [-0800], Paul E. McKenney wrote:
> > Yes, but it triggers frequently. Like `rcuc' is somehow is aligned with
> > the timeout.
>
> Given that a lot of RCU processing is event-driven based on timers,
> and given that the scheduling-clock interrupts are synchronized for
> energ
On Mon, Dec 07, 2020 at 04:25:33PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-12-07 15:29:50 [+0100], Thomas Gleixner wrote:
> > On Mon, Dec 07 2020 at 14:07, Sebastian Andrzej Siewior wrote:
> > > One thing I noticed while testing it is that the "corner" case in
> > > timer_sync_wait_runnin
On 2020-12-07 15:29:50 [+0100], Thomas Gleixner wrote:
> On Mon, Dec 07 2020 at 14:07, Sebastian Andrzej Siewior wrote:
> > One thing I noticed while testing it is that the "corner" case in
> > timer_sync_wait_running() is quite reliably hit by rcu_preempt
> > rcu_gp_fqs_loop() -> swait_event_idle_
On Mon, Dec 07 2020 at 14:07, Sebastian Andrzej Siewior wrote:
> On 2020-12-06 22:40:07 [+0100], Thomas Gleixner wrote:
>> syzbot reported KCSAN data races vs. timer_base::timer_running being set to
>> NULL without holding base::lock in expire_timers().
>>
>> This looks innocent and most reads are
On 2020-12-06 22:40:07 [+0100], Thomas Gleixner wrote:
> syzbot reported KCSAN data races vs. timer_base::timer_running being set to
> NULL without holding base::lock in expire_timers().
>
> This looks innocent and most reads are clearly not problematic but for a
> non-RT kernel it's completely ir
On Mon, Dec 07, 2020 at 01:25:13PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 07, 2020 at 02:10:13AM +0100, Frederic Weisbecker wrote:
> > On Sun, Dec 06, 2020 at 10:40:07PM +0100, Thomas Gleixner wrote:
> > > syzbot reported KCSAN data races vs. timer_base::timer_running being set
> > > to
> > >
On Mon, Dec 07, 2020 at 02:10:13AM +0100, Frederic Weisbecker wrote:
> On Sun, Dec 06, 2020 at 10:40:07PM +0100, Thomas Gleixner wrote:
> > syzbot reported KCSAN data races vs. timer_base::timer_running being set to
> > NULL without holding base::lock in expire_timers().
> >
> > This looks innocen
On Sun, Dec 06, 2020 at 10:40:07PM +0100, Thomas Gleixner wrote:
> syzbot reported KCSAN data races vs. timer_base::timer_running being set to
> NULL without holding base::lock in expire_timers().
>
> This looks innocent and most reads are clearly not problematic but for a
> non-RT kernel it's com
On Fri, 10 Feb 2017, Steven Rostedt wrote:
> On Fri, 10 Feb 2017 15:37:11 +0100 (CET)
> Thomas Gleixner wrote:
>
> > > > --- a/include/trace/events/timer.h
> > > > +++ b/include/trace/events/timer.h
> > > > @@ -36,6 +36,13 @@ DEFINE_EVENT(timer_class, timer_init,
> > > > TP_ARGS(timer)
>
On Fri, 10 Feb 2017 15:37:11 +0100 (CET)
Thomas Gleixner wrote:
> > > --- a/include/trace/events/timer.h
> > > +++ b/include/trace/events/timer.h
> > > @@ -36,6 +36,13 @@ DEFINE_EVENT(timer_class, timer_init,
> > > TP_ARGS(timer)
> > > );
> > >
> > > +#define decode_timer_flags(flags)
On Fri, 10 Feb 2017, Steven Rostedt wrote:
> On Fri, 10 Feb 2017 14:25:03 +0100 (CET)
> Thomas Gleixner wrote:
>
> > The timer flags in the timer_start trace event contain lots of useful
> > information, but the meaning is not clear in the trace output because its
> > just printed as a hex value
On Fri, 10 Feb 2017 14:25:03 +0100 (CET)
Thomas Gleixner wrote:
> The timer flags in the timer_start trace event contain lots of useful
> information, but the meaning is not clear in the trace output because its
> just printed as a hex value. Making tools rely on the bit positions is bad
> as the
On Fri, Jan 29, 2016 at 04:27:35PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 15, 2016 at 03:14:10PM -0800, Paul E. McKenney wrote:
> > And if I make the scheduling-clock interrupt send extra wakeups to the RCU
> > grace-period kthread when needed, things work even with CPU hotplug going.
> >
> >
On Fri, Jan 15, 2016 at 03:14:10PM -0800, Paul E. McKenney wrote:
> And if I make the scheduling-clock interrupt send extra wakeups to the RCU
> grace-period kthread when needed, things work even with CPU hotplug going.
>
> The "when needed" means any time that the RCU grace-period kthread has
> b
On Tue, 2014-07-08 at 04:50PM -0700, Sören Brinkmann wrote:
> Let me extend the audience a bit.
>
> On Mon, 2014-06-30 at 11:39AM -0700, Sören Brinkmann wrote:
> > Hi,
> >
> > I'm currently working on suspend for Zynq and try to track down some
> > spurious wakes. It looks like the spurious wakes
Let me extend the audience a bit.
On Mon, 2014-06-30 at 11:39AM -0700, Sören Brinkmann wrote:
> Hi,
>
> I'm currently working on suspend for Zynq and try to track down some
> spurious wakes. It looks like the spurious wakes are caused by timers,
> hence I was wondering whether there are any speci
On Thu, 2014-07-03 at 07:46PM +0200, Daniel Lezcano wrote:
> On 07/03/2014 07:40 PM, Sören Brinkmann wrote:
> >On Thu, 2014-07-03 at 07:26PM +0200, Daniel Lezcano wrote:
> >>On 07/03/2014 06:09 PM, Sören Brinkmann wrote:
> >>>On Thu, 2014-07-03 at 02:21PM +0200, Daniel Lezcano wrote:
> On 06/30
On 07/03/2014 07:40 PM, Sören Brinkmann wrote:
On Thu, 2014-07-03 at 07:26PM +0200, Daniel Lezcano wrote:
On 07/03/2014 06:09 PM, Sören Brinkmann wrote:
On Thu, 2014-07-03 at 02:21PM +0200, Daniel Lezcano wrote:
On 06/30/2014 08:39 PM, Sören Brinkmann wrote:
Hi,
I'm currently working on susp
On 07/03/2014 07:30 PM, Sören Brinkmann wrote:
On Thu, 2014-07-03 at 07:26PM +0200, Daniel Lezcano wrote:
On 07/03/2014 06:09 PM, Sören Brinkmann wrote:
On Thu, 2014-07-03 at 02:21PM +0200, Daniel Lezcano wrote:
On 06/30/2014 08:39 PM, Sören Brinkmann wrote:
Hi,
I'm currently working on susp
On Thu, 2014-07-03 at 07:26PM +0200, Daniel Lezcano wrote:
> On 07/03/2014 06:09 PM, Sören Brinkmann wrote:
> >On Thu, 2014-07-03 at 02:21PM +0200, Daniel Lezcano wrote:
> >>On 06/30/2014 08:39 PM, Sören Brinkmann wrote:
> >>>Hi,
> >>>
> >>>I'm currently working on suspend for Zynq and try to track
On Thu, 2014-07-03 at 07:26PM +0200, Daniel Lezcano wrote:
> On 07/03/2014 06:09 PM, Sören Brinkmann wrote:
> >On Thu, 2014-07-03 at 02:21PM +0200, Daniel Lezcano wrote:
> >>On 06/30/2014 08:39 PM, Sören Brinkmann wrote:
> >>>Hi,
> >>>
> >>>I'm currently working on suspend for Zynq and try to track
On 07/03/2014 06:09 PM, Sören Brinkmann wrote:
On Thu, 2014-07-03 at 02:21PM +0200, Daniel Lezcano wrote:
On 06/30/2014 08:39 PM, Sören Brinkmann wrote:
Hi,
I'm currently working on suspend for Zynq and try to track down some
spurious wakes. It looks like the spurious wakes are caused by timer
On Thu, 2014-07-03 at 02:21PM +0200, Daniel Lezcano wrote:
> On 06/30/2014 08:39 PM, Sören Brinkmann wrote:
> >Hi,
> >
> >I'm currently working on suspend for Zynq and try to track down some
> >spurious wakes. It looks like the spurious wakes are caused by timers,
> >hence I was wondering whether t
On 06/30/2014 08:39 PM, Sören Brinkmann wrote:
Hi,
I'm currently working on suspend for Zynq and try to track down some
spurious wakes. It looks like the spurious wakes are caused by timers,
hence I was wondering whether there are any special requirements for
timer drivers when it comes to suspe
On Mon, 3 Dec 2007, Pavel Machek wrote:
> On Mon 2007-12-03 22:45:06, Guennadi Liakhovetski wrote:
> > On Sun, 2 Dec 2007, Pavel Machek wrote:
> >
> > > > I compiled a .24-ish kernel for it with CONFIG_NO_HZ and
> > > > CONFIG_HIGH_RES_TIMERS. To get the system boot at least sometimes I
> > > >
Guennadi Liakhovetski wrote:
On Tue, 4 Dec 2007, Robert Hancock wrote:
Guennadi Liakhovetski wrote:
I've got an old 2xP-II @ 400MHz Compaq AP400 system, which I'm still using.
It has many peculiarities, so, I wouldn't be surprised if the answer to my
questions would be "sorry, the patient is r
On Tue, 4 Dec 2007, Robert Hancock wrote:
> Guennadi Liakhovetski wrote:
> >
> > I've got an old 2xP-II @ 400MHz Compaq AP400 system, which I'm still using.
> > It has many peculiarities, so, I wouldn't be surprised if the answer to my
> > questions would be "sorry, the patient is rather dead tha
Guennadi Liakhovetski wrote:
Hi,
I've got an old 2xP-II @ 400MHz Compaq AP400 system, which I'm still
using. It has many peculiarities, so, I wouldn't be surprised if the
answer to my questions would be "sorry, the patient is rather dead than
alive".
Some of the problems lie in ACPI area, I
On Mon, 3 Dec 2007, Pavel Machek wrote:
> On Mon 2007-12-03 22:45:06, Guennadi Liakhovetski wrote:
> > On Sun, 2 Dec 2007, Pavel Machek wrote:
>
> > > > CR0: 8005003b CR2: 081dcf88 CR3: 07e46000 CR4: 02d0
> > > > DR0: DR1: DR2: DR3:
> > > > DR6: 0ff0 DR
On Mon 2007-12-03 22:45:06, Guennadi Liakhovetski wrote:
> On Sun, 2 Dec 2007, Pavel Machek wrote:
>
> > > I compiled a .24-ish kernel for it with CONFIG_NO_HZ and
> > > CONFIG_HIGH_RES_TIMERS. To get the system boot at least sometimes I have
> > > to specify nohz=off. Then I get
> >
> > Try hi
On Sun, 2 Dec 2007, Pavel Machek wrote:
> > I compiled a .24-ish kernel for it with CONFIG_NO_HZ and
> > CONFIG_HIGH_RES_TIMERS. To get the system boot at least sometimes I have
> > to specify nohz=off. Then I get
>
> Try highres=off, too... Hehe, and even idle=poll might help.
Ok, for now I'v
Hi!
> I've got an old 2xP-II @ 400MHz Compaq AP400 system, which I'm still
> using. It has many peculiarities, so, I wouldn't be surprised if the
> answer to my questions would be "sorry, the patient is rather dead than
> alive".
>
> Some of the problems lie in ACPI area, I tried some time ago
If u search for usleep in google then first document says that usleep will
have max range of 1,000,000 microseconds as the max sleep delay and
after the delay time expires the actual execution may get delayed because
of high system activity.
If you are writing kernel modules, you may use schedule
On Sun, May 13, 2001 at 05:45:13PM +0100, Matt wrote:
> I'm having some major headaches trying to get a timer working in my
> driver.
>
> The timer is started when the device node is opened, and deleted when it's
> closed. The timer code itself calls mod_timer to add itself back in
> again. At th
37 matches
Mail list logo
