>> I was trying to tackle the "hard problem" of making *all* time reads
>> non-blocking, with monotonicity guarantees. There has to be *some* bound
>> on blocking times (in particular, time between reading hardware tiemrs
>> and translating them to real time), but they can be reasonably long.
>
- Original Message -
> From: "George Spelvin"
> To: li...@horizon.com, "mathieu desnoyers"
> Cc: "john stultz" , linux-kernel@vger.kernel.org,
> pet...@infradead.org, t...@linutronix.de
> Sent: Tuesday, May 13, 2014 9:29:18 AM
> Subject:
> We could expose a new clock type (besides monotonic and realtime) that is
> documented as non-strictly monotonic. It may return a time very slightly in
> the past if readers race with clock source frequency change. The caller could
> handle this situation (e.g. in user-space) by keeping its own
- Original Message -
> From: "George Spelvin"
> To: "john stultz" , li...@horizon.com
> Cc: linux-kernel@vger.kernel.org, "mathieu desnoyers"
>
> Sent: Tuesday, May 13, 2014 1:13:24 AM
> Subject: Re: [PATCH 4/4] timekeeping: Use pri
printk_deferred when holding
timekeeping seqlock
2) Using wait-free coding techniques where readers help the writer if
they notice a stall. This is much hairier internal code, but makes
life easier on the callers. The basic procedure is:
- A conventionally locked writer
We could expose a new clock type (besides monotonic and realtime) that is
documented as non-strictly monotonic. It may return a time very slightly in
the past if readers race with clock source frequency change. The caller could
handle this situation (e.g. in user-space) by keeping its own
Subject: Re: [PATCH 4/4] timekeeping: Use printk_deferred when holding
timekeeping seqlock
We could expose a new clock type (besides monotonic and realtime) that is
documented as non-strictly monotonic. It may return a time very slightly in
the past if readers race with clock source
I was trying to tackle the hard problem of making *all* time reads
non-blocking, with monotonicity guarantees. There has to be *some* bound
on blocking times (in particular, time between reading hardware tiemrs
and translating them to real time), but they can be reasonably long.
What I
>> 2) Using wait-free coding techniques where readers help the writer if
>>they notice a stall. This is much hairier internal code, but makes
>>life easier on the callers. The basic procedure is:
>>
>>- A conventionally locked writer decides that the frequency is to be
>>
On 05/12/2014 07:44 PM, George Spelvin wrote:
> On Mon, 12 May 2014, John Stultz wrote:
>> First: My apologies, for some reason your mail got tagged as spam, so I
>> only saw it just now looking for another missing email.
> No problem; it happens to everyone. Curse you, Canter & Siegel!
>
>>> One
On Mon, 12 May 2014, John Stultz wrote:
> First: My apologies, for some reason your mail got tagged as spam, so I
> only saw it just now looking for another missing email.
No problem; it happens to everyone. Curse you, Canter & Siegel!
>> One misfeature in the timekeeping seqlock code I noticed
First: My apologies, for some reason your mail got tagged as spam, so I
only saw it just now looking for another missing email.
On 05/06/2014 02:33 PM, George Spelvin wrote:
> One misfeature in the timekeeping seqlock code I noticed is that
> read_seqcount_begin returns "unsigned int", not
First: My apologies, for some reason your mail got tagged as spam, so I
only saw it just now looking for another missing email.
On 05/06/2014 02:33 PM, George Spelvin wrote:
One misfeature in the timekeeping seqlock code I noticed is that
read_seqcount_begin returns unsigned int, not unsigned
On Mon, 12 May 2014, John Stultz wrote:
First: My apologies, for some reason your mail got tagged as spam, so I
only saw it just now looking for another missing email.
No problem; it happens to everyone. Curse you, Canter Siegel!
One misfeature in the timekeeping seqlock code I noticed is
On 05/12/2014 07:44 PM, George Spelvin wrote:
On Mon, 12 May 2014, John Stultz wrote:
First: My apologies, for some reason your mail got tagged as spam, so I
only saw it just now looking for another missing email.
No problem; it happens to everyone. Curse you, Canter Siegel!
One misfeature
2) Using wait-free coding techniques where readers help the writer if
they notice a stall. This is much hairier internal code, but makes
life easier on the callers. The basic procedure is:
- A conventionally locked writer decides that the frequency is to be
adjusted,
One misfeature in the timekeeping seqlock code I noticed is that
read_seqcount_begin returns "unsigned int", not "unsigned long".
Casting to a larger type is harmless, but inefficient.
> This is due to printk() triggering console sem wakeup, which can
> cause scheduling code to trigger hrtimers
One misfeature in the timekeeping seqlock code I noticed is that
read_seqcount_begin returns unsigned int, not unsigned long.
Casting to a larger type is harmless, but inefficient.
This is due to printk() triggering console sem wakeup, which can
cause scheduling code to trigger hrtimers which
Jiri Bohac pointed out that there are rare but potential deadlock
possibilities when calling printk while holding the timekeeping
seqlock.
This is due to printk() triggering console sem wakeup, which can
cause scheduling code to trigger hrtimers which may try to read
the time.
Specifically, as
Jiri Bohac pointed out that there are rare but potential deadlock
possibilities when calling printk while holding the timekeeping
seqlock.
This is due to printk() triggering console sem wakeup, which can
cause scheduling code to trigger hrtimers which may try to read
the time.
Specifically, as
Jiri Bohac pointed out that there are rare but potential deadlock
possibilities when calling printk while holding the timekeeping
seqlock.
This is due to printk() triggering console sem wakeup, which can
cause scheduling code to trigger hrtimers which may try to read
the time.
Specifically, as
Jiri Bohac pointed out that there are rare but potential deadlock
possibilities when calling printk while holding the timekeeping
seqlock.
This is due to printk() triggering console sem wakeup, which can
cause scheduling code to trigger hrtimers which may try to read
the time.
Specifically, as
22 matches
Mail list logo
