On Thu, Jun 16, 2016 at 05:40:51PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 16, 2016 at 08:14:02PM +0200, Peter Zijlstra wrote:
> > On Thu, Jun 16, 2016 at 09:02:15AM -0700, Paul E. McKenney wrote:
> > > > 2) When we do that right, we can make the tick frequency a command line
> > > > option
>
On Thu, Jun 16, 2016 at 08:14:02PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 16, 2016 at 09:02:15AM -0700, Paul E. McKenney wrote:
> > > 2) When we do that right, we can make the tick frequency a command line
> > > option
> > >and just have a compiled in default.
> >
> > As long as there is
On Thu, Jun 16, 2016 at 09:02:15AM -0700, Paul E. McKenney wrote:
> > 2) When we do that right, we can make the tick frequency a command line
> > option
> >and just have a compiled in default.
>
> As long as there is something that tells RCU what the tick frequency
> actually is at runtime, t
On Thu, 16 Jun 2016, Arjan van de Ven wrote:
> I think there's 2 elements on the interface.
>
> 1) having a relative interface to the current time (avoid use of
> absolute jiffies in drivers)
That's the easy part :)
> 2) having wallclock units. Making HZ always be 1000 is effectively
> doing t
I think there's 2 elements on the interface.
1) having a relative interface to the current time (avoid use of
absolute jiffies in drivers)
2) having wallclock units. Making HZ always be 1000 is effectively
doing that as well (1 msec after all)
On Thu, Jun 16, 2016 at 8:43 AM, Thomas Gleixner
On Thu, Jun 16, 2016 at 05:43:36PM +0200, Thomas Gleixner wrote:
> On Wed, 15 Jun 2016, Thomas Gleixner wrote:
> > On Wed, 15 Jun 2016, Arjan van de Ven wrote:
> > > what would 1 more timer wheel do?
> >
> > Waste storage space and make the collection of expired timers more
> > expensive.
> >
>
On Wed, 15 Jun 2016, Thomas Gleixner wrote:
> On Wed, 15 Jun 2016, Arjan van de Ven wrote:
> > what would 1 more timer wheel do?
>
> Waste storage space and make the collection of expired timers more expensive.
>
> The selection of the timer wheel properties is combination of:
>
> 1) Granula
On Wed, 15 Jun 2016, Arjan van de Ven wrote:
> what would 1 more timer wheel do?
Waste storage space and make the collection of expired timers more expensive.
The selection of the timer wheel properties is combination of:
1) Granularity
2) Storage space
3) Number of levels to coll
On Wed, Jun 15, 2016 at 7:53 AM, Thomas Gleixner wrote:
> On Tue, 14 Jun 2016, Eric Dumazet wrote:
>> Original TCP RFCs tell timeout is infinite ;)
>>
>> Practically, conntrack has a 5 days timeout, but I really doubt anyone
>> expects an idle TCP flow to stay 'alive' when nothing is sent for 5
>>
what would 1 more timer wheel do?
On Wed, Jun 15, 2016 at 7:53 AM, Thomas Gleixner wrote:
> On Tue, 14 Jun 2016, Eric Dumazet wrote:
>> Original TCP RFCs tell timeout is infinite ;)
>>
>> Practically, conntrack has a 5 days timeout, but I really doubt anyone
>> expects an idle TCP flow to stay 'a
On Tue, 14 Jun 2016, Eric Dumazet wrote:
> Original TCP RFCs tell timeout is infinite ;)
>
> Practically, conntrack has a 5 days timeout, but I really doubt anyone
> expects an idle TCP flow to stay 'alive' when nothing is sent for 5
> days.
So would 37hrs ~= 1.5 days be a reasonable cutoff or wi
On Tue, Jun 14, 2016 at 1:42 PM, Peter Zijlstra wrote:
> On Tue, Jun 14, 2016 at 08:05:49PM +0200, Thomas Gleixner wrote:
>> On Tue, 14 Jun 2016, Arjan van de Ven wrote:
>>
>> > evaluating a 120 hours timer ever 37 hours to see if it should fire...
>> > not too horrid.
>>
>> Well that thing is doi
On Tue, Jun 14, 2016 at 08:05:49PM +0200, Thomas Gleixner wrote:
> On Tue, 14 Jun 2016, Arjan van de Ven wrote:
>
> > evaluating a 120 hours timer ever 37 hours to see if it should fire...
> > not too horrid.
>
> Well that thing is doing weird stuff anyway:
>
>swapper 0 [001] 1789995.305
On Tue, Jun 14, 2016 at 08:05:49PM +0200, Thomas Gleixner wrote:
> On Tue, 14 Jun 2016, Arjan van de Ven wrote:
>
> > evaluating a 120 hours timer ever 37 hours to see if it should fire...
> > not too horrid.
>
> Well that thing is doing weird stuff anyway:
>
>swapper 0 [001] 1789995.305
Thomas Gleixner wrote:
> On Tue, 14 Jun 2016, George Spelvin wrote:
>> If you need to shrink TIMER_ARRAYMASK to fit another flag bit,
>
> We can accomodate wheel with 512 buckets with the current ARRAYMASK and that
> really should be enough.
You're absolutely correct, but I was referring to the p
On Tue, 14 Jun 2016, Arjan van de Ven wrote:
> evaluating a 120 hours timer ever 37 hours to see if it should fire...
> not too horrid.
Well that thing is doing weird stuff anyway:
swapper 0 [001] 1789995.305532: timer:timer_start:
timer=0x8800c8346920 function=death_by_timeout expir
evaluating a 120 hours timer ever 37 hours to see if it should fire...
not too horrid.
On Tue, Jun 14, 2016 at 9:28 AM, Thomas Gleixner wrote:
> On Tue, 14 Jun 2016, Ingo Molnar wrote:
>> * Thomas Gleixner wrote:
>> > On Mon, 13 Jun 2016, Peter Zijlstra wrote:
>> > > On Mon, Jun 13, 2016 at 08:4
On Tue, 14 Jun 2016, George Spelvin wrote:
> Not enough to be interesting, and the extra levels increase processing
> time. If you need to shrink TIMER_ARRAYMASK to fit another flag bit,
> the easier way would be to encode only the level rather than the index,
> since you can derive the latter fro
On Tue, 14 Jun 2016, Ingo Molnar wrote:
> * Thomas Gleixner wrote:
> > On Mon, 13 Jun 2016, Peter Zijlstra wrote:
> > > On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote:
> > > > +
> > > > + /* Cascading, sigh... */
> > >
> > > So given that userspace has no influence on timer
Peter Zijlstra wrote:
> That did occur to me as well; however I think it would be best to
> eradicate all forms of cascading entirely -- if at all possible.
Agreed.
>> to be replaced with __builtin_clz or similar:
> Problem is for the archs that don't have that, the 5 layer branch is
> trivial f
On Tue, Jun 14, 2016 at 04:16:02AM -0400, George Spelvin wrote:
> While I like the cleanup of just limiting long-term resolution, if
> it turns out to be necessary, it's not too hard to add exact timers
> back in if a need is found in future. All you need is a second
> __internal_add_timer functio
On Tue, 14 Jun 2016, Thomas Gleixner wrote:
> I thought about that and when looking at those long timeout thingies
> I came to the conclusion that it's simply not worth the trouble.
Okay. A comment might be nice, just to stop someone else wasting
brain power on it. E.g.
/*
* If the timer happe
* Thomas Gleixner wrote:
> On Mon, 13 Jun 2016, Peter Zijlstra wrote:
> > On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote:
> > > +
> > > + /* Cascading, sigh... */
> >
> > So given that userspace has no influence on timer period; can't we
> > simply fail to support timers longer
On Tue, 14 Jun 2016, George Spelvin wrote:
> I think I see a buglet in your level-5 cascading.
>
> Suppose a timer is requested far in the future for a time
> that is an exact multiple of 32768 jiffies.
>
> collect_expired_timers() scans level 5 after all the previous ones,
> and will cascade it
Nice cleanup!
I think I see a buglet in your level-5 cascading.
Suppose a timer is requested far in the future for a time
that is an exact multiple of 32768 jiffies.
collect_expired_timers() scans level 5 after all the previous ones,
and will cascade it to level 0, in a level-0 bucket which has
On Mon, 13 Jun 2016, Richard Cochran wrote:
> On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote:
> > +static inline struct timer_base *get_timer_base(u32 tflags)
> > +{
> > + return get_timer_cpu_base(tflags, tflags & TIMER_BASEMASK);
> > +}
>
> This should rather be (tflags & TIME
On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote:
> +static inline struct timer_base *get_timer_base(u32 tflags)
> +{
> + return get_timer_cpu_base(tflags, tflags & TIMER_BASEMASK);
> +}
This should rather be (tflags & TIMER_CPUMASK) to avoid using
per_cpu_ptr() with the TIMER_M
On Mon, 13 Jun 2016, Eric Dumazet wrote:
> On Mon, Jun 13, 2016 at 5:30 AM, Thomas Gleixner wrote:
> > On Mon, 13 Jun 2016, Peter Zijlstra wrote:
> >> On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote:
> >> > +
> >> > + /* Cascading, sigh... */
> >>
> >> So given that userspace has
On Mon, Jun 13, 2016 at 5:30 AM, Thomas Gleixner wrote:
> On Mon, 13 Jun 2016, Peter Zijlstra wrote:
>> On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote:
>> > +
>> > + /* Cascading, sigh... */
>>
>> So given that userspace has no influence on timer period; can't we
>> simply fail
On Mon, 13 Jun 2016, Peter Zijlstra wrote:
> On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote:
> > +
> > + /* Cascading, sigh... */
>
> So given that userspace has no influence on timer period; can't we
> simply fail to support timers longer than 30 minutes?
>
> In anything reall
On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote:
> + * HZ 1000
> + * Level Offset GranularityRange
> + * 0 0 1 ms 0 ms - 63 ms
> + * 1 64 8 ms64 ms -511 ms
> + * 2 128 64 ms 5
The current timer wheel has some drawbacks:
1) Cascading
Cascading can be an unbound operation and is completely pointless in most
cases because the vast majority of the timer wheel timers are canceled or
rearmed before expiration.
2) No fast lookup of the next expiring timer
In NOH
32 matches
Mail list logo
