On Mon, 8 Jun 2015, John Stultz wrote:
> On Mon, Jun 8, 2015 at 12:44 AM, Thomas Gleixner wrote:
> > Well, the problem is that we need to fetch that data on several
> > occasions:
> >
> > - hrtimer_start (if it is the first expiring timer of a clock)
> > - hrtimer_reprogram (after
On Mon, Jun 8, 2015 at 12:44 AM, Thomas Gleixner wrote:
> On Fri, 5 Jun 2015, John Stultz wrote:
>> On Fri, Jun 5, 2015 at 3:07 AM, Ingo Molnar wrote:
>> > * Thomas Gleixner wrote:
>> >> It's not about copying 24 bytes. It's about touching 3 cache lines for
>> >> nothing.
>> >> In situations wh
On Fri, 5 Jun 2015, John Stultz wrote:
> On Fri, Jun 5, 2015 at 3:07 AM, Ingo Molnar wrote:
> > * Thomas Gleixner wrote:
> >> It's not about copying 24 bytes. It's about touching 3 cache lines for
> >> nothing.
> >> In situations where we run high frequency periodic timers on clock
> >> monoton
On Fri, Jun 5, 2015 at 3:07 AM, Ingo Molnar wrote:
>
> * Thomas Gleixner wrote:
>
>> On Thu, 4 Jun 2015, John Stultz wrote:
>> > On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler wrote:
>> > So I suspect the problem is the change to clock_was_set_seq in
>> > timekeeping_update is done prior to mir
On Fri, 5 Jun 2015, Thomas Gleixner wrote:
> On Thu, 4 Jun 2015, John Stultz wrote:
> > On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler wrote:
> > So I suspect the problem is the change to clock_was_set_seq in
> > timekeeping_update is done prior to mirroring the time state to the
> > shadow-time
* Thomas Gleixner wrote:
> On Thu, 4 Jun 2015, John Stultz wrote:
> > On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler wrote:
> > So I suspect the problem is the change to clock_was_set_seq in
> > timekeeping_update is done prior to mirroring the time state to the
> > shadow-timekeeper. Thus the
On Thu, 4 Jun 2015, John Stultz wrote:
> On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler wrote:
> So I suspect the problem is the change to clock_was_set_seq in
> timekeeping_update is done prior to mirroring the time state to the
> shadow-timekeeper. Thus the next time we do update_wall_time() th
* John Stultz wrote:
> So I suspect the problem is the change to clock_was_set_seq in
> timekeeping_update is done prior to mirroring the time state to the
> shadow-timekeeper. Thus the next time we do update_wall_time() the updated
> sequence is overwritten by whats in the shadow copy. The a
John,
On Thu, Jun 04, 2015 at 03:54:35PM -0700, John Stultz wrote:
> On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler wrote:
[...]
>
>
> So I suspect the problem is the change to clock_was_set_seq in
> timekeeping_update is done prior to mirroring the time state to the
> shadow-timekeeper. Thus
On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler wrote:
> all,
>
> After a fresh boot, the Chrome web browser behaves normally. Pages
> load quickly and scroll fast. Even image heavy sites such as
> images.google.com work fine. However, after a suspend and resume
> cycle, Chrome becomes very slo
Thomas,
On Thu, Jun 04, 2015 at 01:22:45PM +0200, Thomas Gleixner wrote:
> On Wed, 3 Jun 2015, Jeremiah Mahler wrote:
[...]
>
> I had to wrap my head around that for quite a while, but I think I
> have decoded the issue. Can you please test the patch below whether it
> solves your problem?
>
> T
On Wed, 3 Jun 2015, Jeremiah Mahler wrote:
> After a fresh boot, the Chrome web browser behaves normally. Pages
> load quickly and scroll fast. Even image heavy sites such as
> images.google.com work fine. However, after a suspend and resume
> cycle, Chrome becomes very slow. Pages take ten sec
12 matches
Mail list logo
