From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Con Kolivas <kernel@kolivas.org>,
linux-kernel@vger.kernel.org, akpm@osdl.org,
ck list <ck@vds.kolivas.org>,
rmk+lkml@arm.linux.org.uk
Subject: Re: [PATCH 1/3] dynticks - implement no idle hz for x86
Date: Tue, 6 Sep 2005 13:51:12 -0700 [thread overview]
Message-ID: <20050906205112.GA3038@us.ibm.com> (raw)
In-Reply-To: <20050905064416.GD25856@us.ibm.com>
On 04.09.2005 [23:44:16 -0700], Nishanth Aravamudan wrote:
> On 05.09.2005 [12:02:29 +0530], Srivatsa Vaddagiri wrote:
> > On Sun, Sep 04, 2005 at 10:48:13PM -0700, Nishanth Aravamudan wrote:
> > > Admittedly, I don't think SMP ARM has been around all that long?
> > > Maybe the existing code just has not been extended.
> >
> > Yeah, maybe ARM never cared for SMP. But we do care :)
>
> I just took a look at arm/Kconfig and SMP is marked as EXPERIMENTAL &&
> BROKEN. So I'm guessing that is the only reason for some of the
> differences you mentioned (the differences are of course, valid and the
> x86 SMP implementation makes sense to me to extend arch-independently).
>
> > > I'm not sure on this. It's going to be NULL for other architectures,
> > > or end up being called by the reprogram() call for the last CPU to
> > > go idle, right (presuming there isn't a separate TOD source, like in
> > > x86). I think it is better to be in the reprogram() interface.
> >
> > Non-x86 could have it set to NULL, in which case it doesn't get
> > called. (I know the current code does not take care of this
> > situation). But having an explicit 'all_cpus_idle' interface may be
> > good, since Tony talked of idling some devices when all CPUs are idle.
> > So it probably has non-x86/PIT uses too.
>
> OK, not a problem. I'll try and write up a general intsource.h file
> (interrupt source header) tonight and tomorrow and send it to this list
> to see if everybody agrees on what's in the structure and where the
> arch-independent/dependent line lies.
Sigh, later than I had hoped, but here is what I have hashed out so far.
Does it seem like a step in the right direction? Rather hand-wavy, but I
think it's mostly correct ;)
Thanks,
Nish
- include/linux/intsource.h
with definitions in kernel/intsource.c
#define DYN_TICK_ENABLED (1 << 1)
#define DYN_TICK_SUITABLE (1 << 0)
#define DYN_TICK_MIN_SKIP 2
/* Abstraction of an interrupt source
* @state: current state
* @max_skip: current maximum number of ticks to skip
* @arch_init: initialization routine
* @arch_enable_dyn_tick: called via sysfs to enable interrupt skipping
* @arch_disable_dyn_tick: called via sysfs to disable interrupt
* skipping
* @arch_set_all_cpus_idle: last cpu to go idle calls this, which should
* disable any timesource (e.g. PIT on x86)
* @arch_recover_time: handler for returning from skipped ticks and keeping
* time consistent
*/
struct interrupt_source {
unsigned int state;
unsigned long max_skip;
int (*arch_init) (void);
void (*arch_enable_dyn_tick) (void);
void (*arch_disable_dyn_tick) (void);
unsigned long (*arch_reprogram) (unsigned long); /* return number of ticks skipped */
unsigned long (*arch_recover_time) (int, void *, struct pt_regs *); /* handler in arm */
/* following empty in UP */
void (*arch_set_all_cpus_idle) (int);
spinlock_t lock;
};
extern void interrupt_source_register(struct interrupt_source *new_interrupt_source);
extern struct interrupt_source *current_intsource;
#ifdef CONFIG_NO_IDLE_HZ
extern void set_interrupt_max_skip(unsigned long max_skip);
/* idle_reprogram_interrupt calls reprogram_interrupt calls current_intsource->arch_reprogram()
* do we really need the first step? */
extern void idle_reprogram_interrupt(void);
/* return number of ticks skipped, potentially for accounting purposes? */
extern unsigned long reprogram_interrupt(void);
extern struct interrupt_source * __init arch_select_interrupt_source(void);
extern void __init dyn_tick_init(void); /* calls select_interrupt_source(), verifies source is usable, then calls interrupt_source_register() */
static inline int dyn_tick_enabled(void)
{
return (current_intsource->state & DYN_TICK_ENABLED);
}
#else /* CONFIG_NO_IDLE_HZ */
static inline void set_interrupt_max_skip(unsigned long max_skip)
{
}
static inline void idle_reprogram_interrupt(void)
{
}
static inline unsigned long reprogram_interrupt(void)
{
return 0;
}
static inline void dyn_tick_init(void)
{
}
static inline int dyn_tick_enabled(void)
{
return 0;
}
#endif /* CONFIG_NO_IDLE_HZ */
/* Pick up arch specific header */
#include <asm/intsource.h>
#endif /* _DYN_TICK_TIMER_H */
- sched.c / sched.h
/* do we want these elsewhere? */
cpumask_t no_idle_hz_cpumask;
* each arch-specific file pair needs to provide:
arch_select_interrupt_source();
appropriate struct interrupt_source definitions, functions, etc.
- include/asm-i386/intsource.h
with defines in arch/i386/intsource.c
- include/asm-arm/arch-omap/intsource.h
with definitions in arch/arm/mach-omap/intsource.c
- include/asm-s390/intsource.h
with definitions in arch/s390/intsource.c
- include/asm-generic/intsource.h
do I need something here?
next prev parent reply other threads:[~2005-09-06 20:51 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-31 16:58 Updated dynamic tick patches Srivatsa Vaddagiri
2005-08-31 17:12 ` [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c Srivatsa Vaddagiri
2005-08-31 22:36 ` Zachary Amsden
2005-08-31 22:47 ` john stultz
2005-09-02 15:43 ` [PATCH 1/3] dynticks - implement no idle hz for x86 Con Kolivas
2005-09-02 15:45 ` [PATCH 2/3] dyntick - Fix lost tick calculation in timer pm.c Con Kolivas
2005-09-02 15:46 ` [PATCH 3/3] dyntick - Recover walltime upon wakeup Con Kolivas
2005-09-02 17:25 ` [PATCH 2/3] dyntick - Fix lost tick calculation in timer pm.c Srivatsa Vaddagiri
2005-09-02 20:18 ` Thomas Schlichter
2005-09-02 21:21 ` john stultz
2005-09-02 16:56 ` [PATCH 1/3] dynticks - implement no idle hz for x86 Russell King
2005-09-02 17:12 ` Srivatsa Vaddagiri
2005-09-03 6:13 ` Con Kolivas
2005-09-03 7:58 ` Russell King
2005-09-03 8:01 ` Con Kolivas
2005-09-03 8:06 ` Russell King
2005-09-03 8:14 ` Con Kolivas
2005-09-04 20:10 ` Nishanth Aravamudan
2005-09-04 20:26 ` Russell King
2005-09-04 20:37 ` Nishanth Aravamudan
2005-09-04 21:17 ` Russell King
2005-09-05 3:08 ` Con Kolivas
2005-09-05 16:28 ` Nishanth Aravamudan
2005-09-05 6:58 ` Tony Lindgren
2005-09-05 16:30 ` Nishanth Aravamudan
2005-09-04 20:41 ` Nishanth Aravamudan
2005-09-05 5:32 ` Srivatsa Vaddagiri
2005-09-05 5:48 ` Nishanth Aravamudan
2005-09-05 6:32 ` Srivatsa Vaddagiri
2005-09-05 6:44 ` Nishanth Aravamudan
2005-09-06 20:51 ` Nishanth Aravamudan [this message]
2005-09-07 8:13 ` Tony Lindgren
2005-09-07 15:00 ` Nishanth Aravamudan
2005-09-07 15:53 ` Nishanth Aravamudan
2005-09-07 17:07 ` Srivatsa Vaddagiri
2005-09-07 17:23 ` Nishanth Aravamudan
2005-09-07 18:14 ` Srivatsa Vaddagiri
2005-09-07 18:22 ` Nishanth Aravamudan
2005-09-07 16:14 ` Bill Davidsen
2005-09-07 16:42 ` Nish Aravamudan
2005-09-07 17:17 ` Srivatsa Vaddagiri
2005-09-07 17:27 ` Nish Aravamudan
2005-09-07 18:18 ` Srivatsa Vaddagiri
2005-09-07 18:33 ` Nish Aravamudan
2005-09-09 16:27 ` Bill Davidsen
2005-09-05 7:37 ` Russell King
2005-09-05 7:49 ` Srivatsa Vaddagiri
2005-09-05 8:00 ` Russell King
2005-09-05 16:33 ` Nishanth Aravamudan
2005-09-05 7:00 ` Srivatsa Vaddagiri
2005-09-05 7:27 ` Tony Lindgren
2005-09-05 17:02 ` Nishanth Aravamudan
2005-09-07 7:37 ` Tony Lindgren
2005-09-07 15:05 ` Nishanth Aravamudan
2005-09-08 10:00 ` Tony Lindgren
2005-09-08 21:22 ` Nishanth Aravamudan
2005-09-08 22:08 ` Nishanth Aravamudan
2005-09-09 22:30 ` Nishanth Aravamudan
2005-09-20 11:06 ` Srivatsa Vaddagiri
2005-09-20 14:58 ` Nishanth Aravamudan
2005-09-22 13:38 ` Martin Schwidefsky
2005-09-22 14:52 ` Nishanth Aravamudan
2005-09-22 18:32 ` Srivatsa Vaddagiri
2005-09-26 15:08 ` Srivatsa Vaddagiri
2005-09-23 6:55 ` Srivatsa Vaddagiri
2005-09-05 7:44 ` Russell King
2005-09-05 8:19 ` Srivatsa Vaddagiri
2005-09-05 8:32 ` Russell King
2005-09-05 9:24 ` Srivatsa Vaddagiri
2005-09-05 17:06 ` Nishanth Aravamudan
2005-09-05 17:04 ` Nishanth Aravamudan
2005-09-05 17:27 ` Srivatsa Vaddagiri
2005-09-05 18:06 ` Nishanth Aravamudan
2005-09-05 13:19 ` Srivatsa Vaddagiri
2005-09-05 16:57 ` Nishanth Aravamudan
2005-09-05 17:25 ` Srivatsa Vaddagiri
2005-09-05 18:11 ` Nishanth Aravamudan
2005-09-03 4:05 ` [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c Lee Revell
2005-09-03 4:18 ` Peter Williams
2005-09-03 4:34 ` Lee Revell
2005-09-03 4:48 ` Peter Williams
2005-09-03 5:15 ` Parag Warudkar
2005-09-03 5:30 ` Lee Revell
2005-09-03 5:20 ` Srivatsa Vaddagiri
2005-09-06 10:32 ` Pavel Machek
2005-09-06 10:46 ` Srivatsa Vaddagiri
2005-09-06 18:04 ` john stultz
2005-08-31 17:26 ` [PATCH 2/3] Updated dynamic tick patches - Cleanup Srivatsa Vaddagiri
2005-08-31 17:27 ` [PATCH 3/3] Updated dynamic tick patches - Recover walltime upon wakeup Srivatsa Vaddagiri
2005-09-01 5:23 ` Updated dynamic tick patches Con Kolivas
2005-09-01 13:07 ` Tony Lindgren
2005-09-01 13:19 ` David Weinehall
2005-09-01 13:46 ` Tony Lindgren
2005-09-01 14:11 ` Srivatsa Vaddagiri
2005-09-02 17:34 ` Srivatsa Vaddagiri
2005-09-03 10:16 ` Tony Lindgren
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=20050906205112.GA3038@us.ibm.com \
--to=nacc@us.ibm.com \
--cc=akpm@osdl.org \
--cc=ck@vds.kolivas.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=vatsa@in.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome