All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: linux-kernel@vger.kernel.org,
	linux-pm@lists.linux-foundation.org, a.p.zijlstra@chello.nl,
	ego@in.ibm.com, tglx@linutronix.de, andi@firstfloor.org,
	venkatesh.pallipadi@intel.com, vatsa@linux.vnet.ibm.com,
	arjan@infradead.org, arun@linux.vnet.ibm.com
Subject: Re: [RFC PATCH 0/4] timers: framework for migration between CPU
Date: Fri, 20 Feb 2009 14:21:45 +0100	[thread overview]
Message-ID: <20090220132145.GF26418@elte.hu> (raw)
In-Reply-To: <20090220125516.GB10232@linux.vnet.ibm.com>


* Arun R Bharadwaj <arun@linux.vnet.ibm.com> wrote:

> Hi,
> 
> 
> In an SMP system, tasks are scheduled on different CPUs by the 
> scheduler, interrupts are managed by irqbalancer daemon, but 
> timers are still stuck to the CPUs that they have been 
> initialised.  Timers queued by tasks gets re-queued on the CPU 
> where the task gets to run next, but timers from IRQ context 
> like the ones in device drivers are still stuck on the CPU 
> they were initialised.  This framework will help move all 
> 'movable timers' from one CPU to any other CPU of choice using 
> a sysfs interface.

hm, the intention is good, the concept of migrating timers to 
their target CPU is good as well. We already do some of that for 
regular timers.

But the whole sysfs interface you implemented here is not 
particularly clean nor is it efficient.

The main problem is that timers are really fast-moving entities, 
and so are the tasks they are related to.

Your implementation completely ties the direction of migration 
(the timer scheduling) to a clumsy sysfs interface:

+	if (sscanf(buf, "%d", &target_cpu) && cpu_online(target_cpu)) {
+               ret = count;
+               per_cpu(enable_timer_migration, cpu->sysdev.id) = target_cpu;
+	}

That doesnt really scale and i doubt it works in practice. We 
should not schedule timers via sysfs, we should let the kernel 
do it auomatically. [*]

So what i'd suggest instead is extend the scheduler power-saving 
code, which already identifies a 'load balancer CPU', to also 
attract all attractable sources of timers - automatically. See 
the 'load_balancer' CPU logic in kernel/sched.c.

Does that sound OK to you? I think the end result might even 
give better numbers - and out of box.

I'd also suggest to not do that rather ugly 
enable_timer_migration per-cpu variable, but simply reuse the 
existing nohz.load_balancer as a target CPU.

Also, please base your patches on the latest timer tree (which 
already modified some of this code in this cycle):

  http://people.redhat.com/mingo/tip.git/README

Btw., could you please also fix your mailer to not do this to 
us:

Mail-Followup-To: linux-kernel@vger.kernel.org,
        linux-pm@lists.linux-foundation.org, a.p.zijlstra@chello.nl,
        ego@in.ibm.com, tglx@linutronix.de, mingo@elte.hu,
        andi@firstfloor.org, venkatesh.pallipadi@intel.com,
        vatsa@linux.vnet.ibm.com, arjan@infradead.org

it messes up the replies.

	Ingo

[*] IRQ migration (where you possibly got the sysfs idea from) 
    is a special case where 'slow scheduling' via a user-space 
    daemon is possible: they are an external source of events 
    and they are concentrators of work. The same concept does 
    not apply to timers, most of which are inherently 
    task-generated.


  parent reply	other threads:[~2009-02-20 13:22 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-20 12:55 [RFC PATCH 0/4] timers: framework for migration between CPU Arun R Bharadwaj
2009-02-20 12:57 ` [RFC PATCH 1/4] timers: framework to identify pinned timers Arun R Bharadwaj
2009-02-20 12:57 ` Arun R Bharadwaj
2009-02-20 12:58 ` [RFC PATCH 2/4] timers: sysfs hook to enable timer migration Arun R Bharadwaj
2009-02-20 12:58 ` Arun R Bharadwaj
2009-02-20 13:00 ` [RFC PATCH 3/4] timers: identifying the existing pinned hrtimers Arun R Bharadwaj
2009-02-20 13:00 ` Arun R Bharadwaj
2009-02-20 13:01 ` [RFC PATCH 4/4] timers: logic to enable timer migration Arun R Bharadwaj
2009-02-20 13:01 ` Arun R Bharadwaj
2009-02-20 13:21 ` Ingo Molnar [this message]
2009-02-20 14:14   ` [RFC PATCH 0/4] timers: framework for migration between CPU Vaidyanathan Srinivasan
2009-02-20 14:14   ` Vaidyanathan Srinivasan
2009-02-20 16:07     ` Ingo Molnar
2009-02-20 16:07     ` Ingo Molnar
2009-02-20 19:57       ` Arjan van de Ven
2009-02-20 21:53         ` Ingo Molnar
2009-02-23  7:55           ` Balbir Singh
2009-02-23  9:11             ` Ingo Molnar
2009-02-23  9:48               ` Balbir Singh
2009-02-23  9:48               ` Balbir Singh
2009-02-23 10:22                 ` Ingo Molnar
2009-02-23 10:22                 ` Ingo Molnar
2009-02-23 11:24                   ` Balbir Singh
2009-02-23 11:24                   ` Balbir Singh
2009-02-23 10:38                 ` Vaidyanathan Srinivasan
2009-02-23 11:07                   ` Ingo Molnar
2009-02-23 11:25                     ` Balbir Singh
2009-02-23 11:25                     ` Balbir Singh
2009-02-26  8:58                     ` Dipankar Sarma
2009-02-26 15:45                       ` Ingo Molnar
2009-02-26 16:02                         ` Peter Zijlstra
2009-02-26 16:12                           ` Ingo Molnar
2009-02-26 16:12                             ` Ingo Molnar
2009-02-26 16:02                         ` Peter Zijlstra
2009-02-26 15:45                       ` Ingo Molnar
2009-02-26  8:58                     ` Dipankar Sarma
2009-02-23 11:07                   ` Ingo Molnar
2009-02-23 10:38                 ` Vaidyanathan Srinivasan
2009-02-23  9:11             ` Ingo Molnar
2009-02-23  7:55           ` Balbir Singh
2009-02-20 21:53         ` Ingo Molnar
2009-02-20 19:57       ` Arjan van de Ven
2009-02-23  7:59   ` Arun R Bharadwaj
2009-02-23  7:59   ` Arun R Bharadwaj
2009-02-20 13:21 ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2009-02-20 12:55 Arun R Bharadwaj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090220132145.GF26418@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=arun@linux.vnet.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=tglx@linutronix.de \
    --cc=vatsa@linux.vnet.ibm.com \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.