On Tue, 2015-05-05 at 15:00 +0200, Thomas Gleixner wrote:
> On Sat, 25 Apr 2015, Eric Dumazet wrote:
> > On Thu, 2015-04-23 at 14:45 +0200, Thomas Gleixner wrote:
> >
> > > You definitely have a point from the high throughput networking
> > > perspective.
> > >
> > > Though in a power optimizing
On Sat, 25 Apr 2015, Eric Dumazet wrote:
> On Thu, 2015-04-23 at 14:45 +0200, Thomas Gleixner wrote:
>
> > You definitely have a point from the high throughput networking
> > perspective.
> >
> > Though in a power optimizing scenario with minimal network traffic
> > this might be the wrong decisi
On Thu, 2015-04-23 at 14:45 +0200, Thomas Gleixner wrote:
> You definitely have a point from the high throughput networking
> perspective.
>
> Though in a power optimizing scenario with minimal network traffic
> this might be the wrong decision. We have to gather data from the
> power maniacs whe
On Wed, 22 Apr 2015, Eric Dumazet wrote:
> On Wed, 2015-04-22 at 23:56 +0200, Thomas Gleixner wrote:
>
> > -int get_nohz_timer_target(int pinned)
> > +int get_nohz_timer_target(void)
> > {
> > - int cpu = smp_processor_id();
> > - int i;
> > + int i, cpu = smp_processor_id();
> > struct
On Wed, 2015-04-22 at 23:56 +0200, Thomas Gleixner wrote:
> -int get_nohz_timer_target(int pinned)
> +int get_nohz_timer_target(void)
> {
> - int cpu = smp_processor_id();
> - int i;
> + int i, cpu = smp_processor_id();
> struct sched_domain *sd;
>
> - if (pinned || !get_
On Wed, 22 Apr 2015, Eric Dumazet wrote:
> On Wed, 2015-04-22 at 20:56 +0200, Thomas Gleixner wrote:
> > On Wed, 22 Apr 2015, Eric Dumazet wrote:
> > > Check commit 4a8e320c929991c9480 ("net: sched: use pinned timers")
> > > for a specific example of the problems that can be raised.
> >
> > If you
On Wed, 2015-04-22 at 20:56 +0200, Thomas Gleixner wrote:
> On Wed, 22 Apr 2015, Eric Dumazet wrote:
> > Check commit 4a8e320c929991c9480 ("net: sched: use pinned timers")
> > for a specific example of the problems that can be raised.
>
> If you have a problem with the core timer code then it shou
On Wed, 22 Apr 2015, Eric Dumazet wrote:
> Check commit 4a8e320c929991c9480 ("net: sched: use pinned timers")
> for a specific example of the problems that can be raised.
If you have a problem with the core timer code then it should be fixed
there and not worked around in some place which will rui
On Wed, 2015-04-22 at 17:29 +0200, Peter Zijlstra wrote:
> Hmm, that sounds unfortunate, this would wreck life for the power aware
> laptop/tablet etc.. people.
>
> There is already a sysctl to manage this, is that not enough to mitigate
> this problem on the server side of things?
The thing is
On Tue, Apr 21, 2015 at 02:54:55PM -0700, Eric Dumazet wrote:
> On Tue, 2015-04-21 at 23:32 +0200, Thomas Gleixner wrote:
>
> >
> > Are you realizing that __mod_timer() is a massive hotpath for network
> > heavy workloads?
>
> BTW I was considering using mod_timer_pinned() from these networking
On Tue, 2015-04-21 at 23:32 +0200, Thomas Gleixner wrote:
>
> Are you realizing that __mod_timer() is a massive hotpath for network
> heavy workloads?
BTW I was considering using mod_timer_pinned() from these networking
timers (ie sk_reset_timer())
get_nohz_timer_target() sounds cool for laptop
On Fri, 17 Apr 2015, viresh kumar wrote:
> Does this look any better ?
Yes, but:
> 1.) Should the above list_empty(migration_list) block be added out of the
>
> while (time_after_eq(jiffies, base->timer_jiffies))
>
> block ? So that we check it only once per timer interrupt.
That's
* viresh kumar wrote:
> + /*
> +* Timer handler re-armed timer and we didn't wanted to add
> that
> +* on a idle local CPU. Its handler has finished now, lets
> +* enqueue it again.
> +*/
That single comment has 5 gr
Hi Thomas,
On Wednesday 15 April 2015 04:43 AM, Thomas Gleixner wrote:
> No new flags in the timer base, no concurrent expiry, no extra
> conditionals in the expiry path. Just a single extra check at the end
> of the softirq handler for this rare condition instead of imposing all
> that nonsense
On Tue, 31 Mar 2015, Viresh Kumar wrote:
> @@ -1213,6 +1249,25 @@ static inline void __run_timers(struct tvec_base *base)
> call_timer_fn(timer, fn, data);
> spin_lock_irq(&base->lock);
> }
> +
> +
On Tue, 31 Mar 2015, Viresh Kumar wrote:
> @@ -1189,12 +1195,41 @@ static inline void __run_timers(struct tvec_base
> *base)
> cascade(base, &base->tv5, INDEX(3));
> ++base->timer_jiffies;
> list_replace_init(base->tv1.vec + index, head);
> +
> +ag
On Tue, Mar 31, 2015 at 12:25:16PM +0530, Viresh Kumar wrote:
> Cc: Steven Miao
> +#define TIMER_FLAG_MASK 0x7LU
So Steven, this will break compilation on blackfin because that makes
cacheline_aligned a NOP while we assume it will generate
__attribute__((__aligned__(SMP
While queuing a timer, we try to migrate it to a non-idle core if the local core
is idle, but we don't try that if the timer is re-armed from its handler.
There were few unsolved problems due to which it was avoided until now. But
there are cases where solving these problems can be useful. When th
18 matches
Mail list logo
