From: Ingo Molnar <mingo@elte.hu>
To: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E. McKenney" <paulmck@us.ibm.com>,
LKML <linux-kernel@vger.kernel.org>, Jim Gettys <jg@laptop.org>,
John Stultz <johnstul@us.ibm.com>,
David Woodhouse <dwmw2@infradead.org>,
Arjan van de Ven <arjan@infradead.org>,
Dave Jones <davej@redhat.com>
Subject: Re: [patch 08/23] dynticks: prepare the RCU code
Date: Sat, 30 Sep 2006 15:09:58 +0200 [thread overview]
Message-ID: <20060930130958.GA12021@elte.hu> (raw)
In-Reply-To: <20060930122514.GC8763@in.ibm.com>
* Dipankar Sarma <dipankar@in.ibm.com> wrote:
> It is duplicating code. That can be easily fixed, but we need to
> figure out what we really want from RCU when we are about to switch
> off the ticks. It is hard if you want to finish off all the pending
> RCUs and go to nohz state. Can you live with backing out if there are
> pending RCUs ?
the thing is that when we go idle we /want/ to process whatever delayed
work there might be - rate limited or not. Do you agree with that
approach? I consider this a performance feature as well: this way we can
utilize otherwise lost idle time. It is not a problem that we dont
'batch' this processing: we are really idle and we've got free cycles to
burn. We could even do an RCU processing loop that immediately breaks
out if need_resched() gets set [by an IRQ or by another CPU].
secondly, i think i saw functionality problems when RCU was not
completed before going idle - for example synchronize_rcu() on another
CPU would hang.
what approach would you suggest to achieve these goals?
Ingo
next prev parent reply other threads:[~2006-09-30 13:18 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-29 23:58 [patch 00/23] Thomas Gleixner
2006-09-29 23:58 ` [patch 01/23] GTOD: exponential update_wall_time Thomas Gleixner
2006-09-29 23:58 ` [patch 02/23] GTOD: persistent clock support, core Thomas Gleixner
2006-09-30 8:35 ` Andrew Morton
2006-09-30 17:15 ` Jan Engelhardt
2006-10-02 21:49 ` john stultz
2006-09-29 23:58 ` [patch 03/23] GTOD: persistent clock support, i386 Thomas Gleixner
2006-09-30 8:36 ` Andrew Morton
2006-10-02 22:03 ` john stultz
2006-10-02 22:44 ` Andrew Morton
2006-10-02 23:09 ` john stultz
2006-10-03 23:30 ` Thomas Gleixner
2006-09-29 23:58 ` [patch 04/23] time: uninline jiffies.h Thomas Gleixner
2006-09-29 23:58 ` [patch 05/23] time: fix msecs_to_jiffies() bug Thomas Gleixner
2006-09-29 23:58 ` [patch 06/23] time: fix timeout overflow Thomas Gleixner
2006-09-29 23:58 ` [patch 07/23] cleanup: uninline irq_enter() and move it into a function Thomas Gleixner
2006-09-30 8:36 ` Andrew Morton
2006-09-29 23:58 ` [patch 08/23] dynticks: prepare the RCU code Thomas Gleixner
2006-09-30 8:36 ` Andrew Morton
2006-09-30 12:25 ` Dipankar Sarma
2006-09-30 13:09 ` Ingo Molnar [this message]
2006-09-30 13:52 ` Dipankar Sarma
2006-09-30 21:35 ` Ingo Molnar
2006-09-29 23:58 ` [patch 09/23] dynticks: extend next_timer_interrupt() to use a reference jiffie Thomas Gleixner
2006-09-30 8:37 ` Andrew Morton
2006-09-29 23:58 ` [patch 10/23] hrtimers: clean up locking Thomas Gleixner
2006-09-30 8:37 ` Andrew Morton
2006-09-29 23:58 ` [patch 11/23] hrtimers: state tracking Thomas Gleixner
2006-09-30 8:37 ` Andrew Morton
2006-09-29 23:58 ` [patch 12/23] hrtimers: clean up callback tracking Thomas Gleixner
2006-09-29 23:58 ` [patch 13/23] clockevents: core Thomas Gleixner
2006-09-30 8:39 ` Andrew Morton
2006-10-03 4:33 ` John Kacur
2006-09-29 23:58 ` [patch 14/23] clockevents: drivers for i386 Thomas Gleixner
2006-09-30 8:40 ` Andrew Morton
2006-09-29 23:58 ` [patch 15/23] high-res timers: core Thomas Gleixner
2006-09-30 8:43 ` Andrew Morton
2006-09-29 23:58 ` [patch 16/23] dynticks: core Thomas Gleixner
2006-09-30 8:44 ` Andrew Morton
2006-09-30 12:11 ` Dipankar Sarma
2006-09-29 23:58 ` [patch 17/23] dyntick: add nohz stats to /proc/stat Thomas Gleixner
2006-09-29 23:58 ` [patch 18/23] dynticks: i386 arch code Thomas Gleixner
2006-09-30 8:45 ` Andrew Morton
2006-09-29 23:58 ` [patch 19/23] high-res timers, dynticks: enable i386 support Thomas Gleixner
2006-09-29 23:58 ` [patch 20/23] add /proc/sys/kernel/timeout_granularity Thomas Gleixner
2006-09-30 8:45 ` Andrew Morton
2006-09-29 23:58 ` [patch 21/23] debugging feature: timer stats Thomas Gleixner
2006-09-30 8:46 ` Andrew Morton
2006-09-29 23:58 ` [patch 22/23] dynticks: increase SLAB timeouts Thomas Gleixner
2006-09-30 8:49 ` Andrew Morton
2006-09-29 23:58 ` [patch 23/23] dynticks: decrease I8042_POLL_PERIOD Thomas Gleixner
2006-09-30 8:49 ` Andrew Morton
2006-09-30 8:35 ` [patch 00/23] Andrew Morton
2006-09-30 19:17 ` Thomas Gleixner
2006-09-30 8:35 ` Andrew Morton
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=20060930130958.GA12021@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=davej@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=dwmw2@infradead.org \
--cc=jg@laptop.org \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@us.ibm.com \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox