On Fri, Dec 02, 2016 at 09:36:42AM +0100, Thomas Gleixner wrote:
> On Fri, 2 Dec 2016, David Gibson wrote:
> > On Thu, Dec 01, 2016 at 12:59:51PM +0100, Thomas Gleixner wrote:
> > > So I assume that you are talking about a VM which was not scheduled by the
> > > host due to overcommitment (who ever
On Fri, 2 Dec 2016, David Gibson wrote:
> On Thu, Dec 01, 2016 at 12:59:51PM +0100, Thomas Gleixner wrote:
> > So I assume that you are talking about a VM which was not scheduled by the
> > host due to overcommitment (who ever thought that this is a good idea) or
> > whatever other reason (yes, peo
On Thu, Dec 01, 2016 at 12:59:51PM +0100, Thomas Gleixner wrote:
> On Thu, 1 Dec 2016, David Gibson wrote:
> > On Thu, Dec 01, 2016 at 12:21:02AM +0100, Thomas Gleixner wrote:
> > > On Wed, 30 Nov 2016, David Gibson wrote:
> > > > On Tue, Nov 29, 2016 at 03:22:17PM +0100, Thomas Gleixner wrote:
> >
On Thu, 1 Dec 2016, John Stultz wrote:
> Yes, you're right here and apologies, as I wasn't being precise. In
> this case time does go backward, but its limited to within the current
> interval (just as it would be with a narrow clocksource wrapping
> fully). But without this patch, when the overfl
On Thu, Dec 1, 2016 at 2:44 PM, Thomas Gleixner wrote:
> On Thu, 1 Dec 2016, John Stultz wrote:
>
>> On Thu, Dec 1, 2016 at 12:46 PM, Thomas Gleixner wrote:
>> > On Thu, 1 Dec 2016, John Stultz wrote:
>> >> I would also suggest:
>> >> 3) If the systems are halted for longer then the timekeeping c
On Thu, 1 Dec 2016, John Stultz wrote:
> On Thu, Dec 1, 2016 at 12:46 PM, Thomas Gleixner wrote:
> > On Thu, 1 Dec 2016, John Stultz wrote:
> >> I would also suggest:
> >> 3) If the systems are halted for longer then the timekeeping core
> >> expects, the system will "miss" or "lose" some portion
On Thu, Dec 1, 2016 at 12:46 PM, Thomas Gleixner wrote:
> On Thu, 1 Dec 2016, John Stultz wrote:
>> I would also suggest:
>> 3) If the systems are halted for longer then the timekeeping core
>> expects, the system will "miss" or "lose" some portion of that halted
>> time, but otherwise the system
On Thu, 1 Dec 2016, John Stultz wrote:
> On Thu, Dec 1, 2016 at 3:59 AM, Thomas Gleixner wrote:
> > So yes, we can make all this unsigned and all worries about negative deltas
> > are moot.
>
> Sorry for the slow response, and thanks David, for stepping in here.
>
> So apologies for not rewritin
On Thu, Dec 1, 2016 at 3:59 AM, Thomas Gleixner wrote:
> On Thu, 1 Dec 2016, David Gibson wrote:
>> But.. delta is a cycle_t, which is typedef'd to u64, so how could it
>> be negative?
>
> Indeed. To be honest I did not bother to look that up and for some reason I
> was assuming that it's a s64. :
On Thu, 1 Dec 2016, David Gibson wrote:
> On Thu, Dec 01, 2016 at 12:21:02AM +0100, Thomas Gleixner wrote:
> > On Wed, 30 Nov 2016, David Gibson wrote:
> > > On Tue, Nov 29, 2016 at 03:22:17PM +0100, Thomas Gleixner wrote:
> > > > If we have legitimate use cases with a negative delta, then this pat
On Thu, Dec 01, 2016 at 12:21:02AM +0100, Thomas Gleixner wrote:
> On Wed, 30 Nov 2016, David Gibson wrote:
> > On Tue, Nov 29, 2016 at 03:22:17PM +0100, Thomas Gleixner wrote:
> > > If we have legitimate use cases with a negative delta, then this patch
> > > breaks them no matter what. See the bas
On Wed, 30 Nov 2016, David Gibson wrote:
> On Tue, Nov 29, 2016 at 03:22:17PM +0100, Thomas Gleixner wrote:
> > If we have legitimate use cases with a negative delta, then this patch
> > breaks them no matter what. See the basic C course section in the second
> > link.
>
> So, fwiw, when I first w
On Tue, Nov 29, 2016 at 03:22:17PM +0100, Thomas Gleixner wrote:
> On Fri, 18 Nov 2016, John Stultz wrote:
> > From: Liav Rehana
> >
> > During the calculation of the nsec variable in the inline function
> > timekeeping_delta_to_ns, it may undergo a sign extension if its msb
> > is set just befor
On Fri, 18 Nov 2016, John Stultz wrote:
> From: Liav Rehana
>
> During the calculation of the nsec variable in the inline function
> timekeeping_delta_to_ns, it may undergo a sign extension if its msb
> is set just before the shift. The sign extension may, in some cases,
> gain it a value near th
On Fri, Nov 18, 2016 at 8:53 PM, John Stultz wrote:
> From: Liav Rehana
>
> During the calculation of the nsec variable in the inline function
> timekeeping_delta_to_ns, it may undergo a sign extension if its msb
> is set just before the shift. The sign extension may, in some cases,
> gain it a v
From: Liav Rehana
During the calculation of the nsec variable in the inline function
timekeeping_delta_to_ns, it may undergo a sign extension if its msb
is set just before the shift. The sign extension may, in some cases,
gain it a value near the maximum value of the 64-bit range. This is
bad whe
On Tue, 27 Sep 2016, Liav Rehana wrote:
> -Original Message-
.
>
Can you pretty please get rid of this --Original Message-- crap. There is
absolutely no value in copying the mail header into every reply.
> On Mon, 26 Sep 2016, Liav Rehana wrote:
> >> During the calculation of the nse
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Tuesday, September 27, 2016 3:01 AM
To: Liav Rehana
Cc: john.stu...@linaro.org; linux-kernel@vger.kernel.org; Elad Kanfi
; Noam Camus
Subject: Re: [PATCH] timekeeping: Change type of nsec variable to unsigned
On Mon, 26 Sep 2016, Liav Rehana wrote:
> During the calculation of the nsec variable in the inline function
> timekeeping_delta_to_ns, it may undergo a sign extension if its msb
> is set just before the shift. The sign extension may, in some cases,
> gain it a value near the maximum value of the 6
From: Liav Rehana
During the calculation of the nsec variable in the inline function
timekeeping_delta_to_ns, it may undergo a sign extension if its msb
is set just before the shift. The sign extension may, in some cases,
gain it a value near the maximum value of the 64-bit range. This is
bad whe
From: Liav Rehana
During the calculation of the nsec variable in the inline function
timekeeping_delta_to_ns, it may undergo a sign extension if its msb
is set just before the shift. The sign extension may, in some cases,
gain it a value near the maximum value of the 64-bit range. This is
bad whe
On Sun, Sep 25, 2016 at 10:45 PM, Liav Rehana wrote:
> From: Liav Rehana
>
> During the calculation of the nsec variable in the inline function
> timekeeping_delta_to_ns, it may undergo a sign extension if its msb
> is set just before the shift. The sign extension may, in some cases,
> gain it a
22 matches
Mail list logo
