accumulated timers which machine is in suspend-to-ram

accumulated timers which machine is in suspend-to-ram

[Stefan Monnier]

Has anything changed in the treatment of timers?
I noticed in the last few weeks that when my machines wake up from
suspend-to-ram, my Emacsen tend to be busy for a while, and apparently
they're busy running savehist-save over and over again.

Does that ring a bell for someone?


        Stefan

Re: accumulated timers which machine is in suspend-to-ram

[Michael Heerdegen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Has anything changed in the treatment of timers?
> I noticed in the last few weeks that when my machines wake up from
> suspend-to-ram, my Emacsen tend to be busy for a while, and apparently
> they're busy running savehist-save over and over again.

I see the same since some weeks.  I hope we can find a cause, it's
annoying.

Michael.

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Mon, 22 Apr 2019 00:04:32 +0200
> Cc: emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
> > Has anything changed in the treatment of timers?
> > I noticed in the last few weeks that when my machines wake up from
> > suspend-to-ram, my Emacsen tend to be busy for a while, and apparently
> > they're busy running savehist-save over and over again.
> 
> I see the same since some weeks.

"The same" meaning that in your case it's also savehist-save that runs
repeatedly?

Re: accumulated timers which machine is in suspend-to-ram

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> "The same" meaning that in your case it's also savehist-save that runs
> repeatedly?

I think so, yes.  I profiled the situation multiple times.
`savehist-save' always had an amount of ~ 60%, also garbage collection
had a large amount.  What I can't say is whether `savehist-save' had
been called repeatedly or if the calls only took extremely long.  I'll
try to use the tracer to check that.

Michael.

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Mon, 22 Apr 2019 20:12:17 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > "The same" meaning that in your case it's also savehist-save that runs
> > repeatedly?
> 
> I think so, yes.  I profiled the situation multiple times.
> `savehist-save' always had an amount of ~ 60%, also garbage collection
> had a large amount.  What I can't say is whether `savehist-save' had
> been called repeatedly or if the calls only took extremely long.  I'll
> try to use the tracer to check that.

Thanks.

Hmm... if by "few weeks" Stefan meant something that could have
started in February, then maybe it's 476066e8?  Or 988e37f?

Re: accumulated timers which machine is in suspend-to-ram

[Stefan Monnier]

> Hmm... if by "few weeks" Stefan meant something that could have
> started in February, then maybe it's 476066e8?  Or 988e37f?

I just saw that Emacs-26.1 also tries to catch up with the N missed
repetitions of timers when we wake up, so the new problem (for which
I haven't yet filed a bug report) is not only due to this behavior (for
which I just filed a bug report).


        Stefan

Re: accumulated timers which machine is in suspend-to-ram

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Hmm... if by "few weeks" Stefan meant something that could have
> started in February, then maybe it's 476066e8?  Or 988e37f?

I've rebuild Emacs with yesterdays master (4bf3c94939) and 476066e8
reverted (apart from some small conflicting parts).  The business after
wake up from suspend to ram was gone.  So unless the issue had been
fixed yesterday 476066e8 seems to be related.

Michael.

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Tue, 23 Apr 2019 22:41:58 +0200
> Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Hmm... if by "few weeks" Stefan meant something that could have
> > started in February, then maybe it's 476066e8?  Or 988e37f?
> 
> I've rebuild Emacs with yesterdays master (4bf3c94939) and 476066e8
> reverted (apart from some small conflicting parts).  The business after
> wake up from suspend to ram was gone.  So unless the issue had been
> fixed yesterday 476066e8 seems to be related.

That's strange, because if you have the same problem as Stefan, I
think this is veteran functionality, see my response in bug#35400.

Re: accumulated timers which machine is in suspend-to-ram

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> That's strange, because if you have the same problem as Stefan, I
> think this is veteran functionality, see my response in bug#35400.

Yes, strange indeed.  But I'm very sure that the original issue (Emacs
busy for quite a long time after wake up) is new.  The latest commits
somehow changed the behavior, so the reason is probably not as trivial
as the bug report suggests.  Maybe the 10 is not honored anymore because
of the integer conversions?  Or something like that?

Michael.

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Wed, 24 Apr 2019 09:21:12 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's strange, because if you have the same problem as Stefan, I
> > think this is veteran functionality, see my response in bug#35400.
> 
> Yes, strange indeed.  But I'm very sure that the original issue (Emacs
> busy for quite a long time after wake up) is new.

So you are unable to reproduce in Emacs 26?

> The latest commits somehow changed the behavior, so the reason is
> probably not as trivial as the bug report suggests.  Maybe the 10 is
> not honored anymore because of the integer conversions?  Or
> something like that?

Do you see more than 10 repetitions of the same timer?  Does the
variable control how many repetitions you see?

Re: accumulated timers which machine is in suspend-to-ram

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> So you are unable to reproduce in Emacs 26?

I was unable to reproduce with 476066e8 reverted, at least.  I can check
with Emacs 26 again.

> > The latest commits somehow changed the behavior, so the reason is
> > probably not as trivial as the bug report suggests.  Maybe the 10 is
> > not honored anymore because of the integer conversions?  Or
> > something like that?
>
> Do you see more than 10 repetitions of the same timer?  Does the
> variable control how many repetitions you see?

For now I'm tracing 'savehist-autosave'.  I get an entry every 5
minutes.  Let's see how many entries I get when Emacs wakes up from Ram
next time.


Michael.

Re: accumulated timers which machine is in suspend-to-ram

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> For now I'm tracing 'savehist-autosave'.  I get an entry every 5
> minutes.  Let's see how many entries I get when Emacs wakes up from
> Ram next time.

143 calls; which fits exactly one call every five minutes for the 11
hours I had suspended to Ram.  But I guess I'm too late cause you
already fixed it.  Will try your fix.

Thanks,

Michael.

Re: accumulated timers which machine is in suspend-to-ram

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Will try your fix.

I can confirm it's fixed.


Thanks,

Michael.

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2019 03:57:29 +0200
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > Will try your fix.
> 
> I can confirm it's fixed.

Great, thank you.

Re: accumulated timers which machine is in suspend-to-ram

[Stefan Monnier]

> That's strange, because if you have the same problem as Stefan, I
> think this is veteran functionality, see my response in bug#35400.

As I said, I think the two issues are separate: my original email
thought that this was the problem, but investigation showed that this
repetition is nothing new, so what we're seeing is caused by
something else.


        Stefan

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Wed, 24 Apr 2019 08:52:15 -0400
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, emacs-devel@gnu.org
> 
> > That's strange, because if you have the same problem as Stefan, I
> > think this is veteran functionality, see my response in bug#35400.
> 
> As I said, I think the two issues are separate: my original email
> thought that this was the problem, but investigation showed that this
> repetition is nothing new, so what we're seeing is caused by
> something else.

So how is what you are seeing different from the "normal" repetition?

Re: accumulated timers which machine is in suspend-to-ram

[Stefan Monnier]

> So how is what you are seeing different from the "normal" repetition?

It can take almost a minute for Emacs to become responsive after
waking up.  That's much more than running savehist-save 10
times, AFAICT.


        Stefan

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: michael_heerdegen@web.de, emacs-devel@gnu.org
> Date: Wed, 24 Apr 2019 09:26:54 -0400
> 
> > So how is what you are seeing different from the "normal" repetition?
> 
> It can take almost a minute for Emacs to become responsive after
> waking up.  That's much more than running savehist-save 10
> times, AFAICT.

And all that time Emacs is running savehist-save?  Or are some other
timers involved?

Re: accumulated timers which machine is in suspend-to-ram

[Stefan Monnier]

> And all that time Emacs is running savehist-save?
> Or are some other timers involved?

I haven't investigated enough yet to be able to tell.


        Stefan

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: michael_heerdegen@web.de, emacs-devel@gnu.org
> Date: Wed, 24 Apr 2019 10:52:41 -0400
> 
> > And all that time Emacs is running savehist-save?
> > Or are some other timers involved?
> 
> I haven't investigated enough yet to be able to tell.

OK, thanks.  I think I see the problem.

Re: accumulated timers which machine is in suspend-to-ram

[Eli Zaretskii]

> Date: Wed, 24 Apr 2019 18:01:23 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: michael_heerdegen@web.de, emacs-devel@gnu.org
> 
> > From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> > Cc: michael_heerdegen@web.de, emacs-devel@gnu.org
> > Date: Wed, 24 Apr 2019 10:52:41 -0400
> > 
> > > And all that time Emacs is running savehist-save?
> > > Or are some other timers involved?
> > 
> > I haven't investigated enough yet to be able to tell.
> 
> OK, thanks.  I think I see the problem.

Should be fixed now.