On Tue, 4 Mar 2014, Andy Lutomirski wrote:
> On Tue, Mar 4, 2014 at 4:10 PM, Thomas Gleixner wrote:
> > A slacked timer still gets enqueued into the main timer queue. It just
> > relies on the fact that it gets batched with some other expiring
> > timer. But thats completely different to the
On Tue, Mar 04, 2014 at 11:11:21PM +0100, Thomas Gleixner wrote:
>
> Once we agree on a solution to the Y2038 issue on 32bit with a unified
> 32/64 bit syscall interface which simply gets rid of the timespec/val
> nonsense and takes a simple u64 nsec value we can add the slack
> property to that
On Tue, Mar 04, 2014 at 11:11:21PM +0100, Thomas Gleixner wrote:
Once we agree on a solution to the Y2038 issue on 32bit with a unified
32/64 bit syscall interface which simply gets rid of the timespec/val
nonsense and takes a simple u64 nsec value we can add the slack
property to that
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
On Tue, Mar 4, 2014 at 4:10 PM, Thomas Gleixner t...@linutronix.de wrote:
A slacked timer still gets enqueued into the main timer queue. It just
relies on the fact that it gets batched with some other expiring
timer. But thats completely different
On Tue, Mar 4, 2014 at 4:10 PM, Thomas Gleixner wrote:
> On Tue, 4 Mar 2014, Andy Lutomirski wrote:
>> On Tue, Mar 4, 2014 at 2:11 PM, Thomas Gleixner wrote:
>> > We do no add another random special case syscall for timerfd just
>> > because timerfd is linux specific.
>>
>> What syscalls? I can
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
> On Tue, Mar 4, 2014 at 2:11 PM, Thomas Gleixner wrote:
> > We do no add another random special case syscall for timerfd just
> > because timerfd is linux specific.
>
> What syscalls? I can think of exactly two timer interfaces that
> actually accept
On Tue, Mar 4, 2014 at 2:11 PM, Thomas Gleixner wrote:
> On Tue, 4 Mar 2014, Andy Lutomirski wrote:
>
>> On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner wrote:
>> > On Tue, 25 Feb 2014, Andy Lutomirski wrote:
>> >> On the other hand, if you added a fancier version of timerfd_settime
>> >> that
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
> On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner wrote:
> > On Tue, 25 Feb 2014, Andy Lutomirski wrote:
> >> On the other hand, if you added a fancier version of timerfd_settime
> >> that could explicitly set the slack value (or, equivalently, the
>
On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner wrote:
> On Tue, 25 Feb 2014, Andy Lutomirski wrote:
>> On the other hand, if you added a fancier version of timerfd_settime
>> that could explicitly set the slack value (or, equivalently, the
>> earliest and latest allowable times), that could be
On Tue, 25 Feb 2014, Andy Lutomirski wrote:
> On 02/20/2014 08:23 AM, Alexey Perevalov wrote:
> > From: Anton Vorontsov
> >
> > This patch implements a userland-side API for generic deferrable timers,
> > per linux/timer.h:
> >
> > * A deferrable timer will work normally when the system is
On Tue, 25 Feb 2014, Andy Lutomirski wrote:
On 02/20/2014 08:23 AM, Alexey Perevalov wrote:
From: Anton Vorontsov an...@enomsg.org
This patch implements a userland-side API for generic deferrable timers,
per linux/timer.h:
* A deferrable timer will work normally when the system is
On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 25 Feb 2014, Andy Lutomirski wrote:
On the other hand, if you added a fancier version of timerfd_settime
that could explicitly set the slack value (or, equivalently, the
earliest and latest allowable times),
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 25 Feb 2014, Andy Lutomirski wrote:
On the other hand, if you added a fancier version of timerfd_settime
that could explicitly set the slack value (or,
On Tue, Mar 4, 2014 at 2:11 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 25 Feb 2014, Andy Lutomirski wrote:
On the other hand, if you added a fancier version of
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
On Tue, Mar 4, 2014 at 2:11 PM, Thomas Gleixner t...@linutronix.de wrote:
We do no add another random special case syscall for timerfd just
because timerfd is linux specific.
What syscalls? I can think of exactly two timer interfaces that
On Tue, Mar 4, 2014 at 4:10 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
On Tue, Mar 4, 2014 at 2:11 PM, Thomas Gleixner t...@linutronix.de wrote:
We do no add another random special case syscall for timerfd just
because timerfd is linux specific.
On 02/20/2014 08:23 AM, Alexey Perevalov wrote:
> From: Anton Vorontsov
>
> This patch implements a userland-side API for generic deferrable timers,
> per linux/timer.h:
>
> * A deferrable timer will work normally when the system is busy, but
> * will not cause a CPU to come out of idle just
On 02/20/2014 08:23 AM, Alexey Perevalov wrote:
From: Anton Vorontsov an...@enomsg.org
This patch implements a userland-side API for generic deferrable timers,
per linux/timer.h:
* A deferrable timer will work normally when the system is busy, but
* will not cause a CPU to come out of
From: Anton Vorontsov
This patch implements a userland-side API for generic deferrable timers,
per linux/timer.h:
* A deferrable timer will work normally when the system is busy, but
* will not cause a CPU to come out of idle just to service it; instead,
* the timer will be serviced when the
From: Anton Vorontsov an...@enomsg.org
This patch implements a userland-side API for generic deferrable timers,
per linux/timer.h:
* A deferrable timer will work normally when the system is busy, but
* will not cause a CPU to come out of idle just to service it; instead,
* the timer will be
20 matches
Mail list logo
