* Re: [MIPS] SMTC: smtc_timer_broadcast ignores its arguments, make it void.
2007-07-27 19:47 ` [MIPS] SMTC: smtc_timer_broadcast ignores its arguments, make it void Kevin D. Kissell
@ 2007-07-27 19:47 ` Kevin D. Kissell
2007-08-04 16:38 ` Ralf Baechle
1 sibling, 0 replies; 3+ messages in thread
From: Kevin D. Kissell @ 2007-07-27 19:47 UTC (permalink / raw)
To: linux-mips
The argument to smtc_timer_broadcast() is supposed to be a VPE number.
Somewhere between the earliest prototypes and the current linux-mips.org
tree, it got hacked up to ignore the argument and broadcast to all TCs.
There are still configurations out there, some of which I've worked on
pretty recently, where the platform code can be configured to either
do global or VPE-local broadcasting of timer interrupts. While we have
determined that it's pretty important to ensure that, in an SMTC configuration,
having the Count registers of all VPEs in sync is important to avoid timing
glitches, skewing the starting Compare values should help even out the load
and reduce contention for the locks on the scheduler queues. Getting rid
of the argument to smtc_timer_broadcast() makes that impossible. I'd
rather see the platform timer code iterate through the configured VPEs
and keep the argument.
The most recent smtc_timer_broadcast() I've worked on looks like:
void smtc_timer_broadcast(int vpe)
{
int cpu;
int myTC = cpu_data[smp_processor_id()].tc_id;
smtc_cpu_stats[smp_processor_id()].timerints++;
for_each_online_cpu(cpu) {
if (cpu_data[cpu].vpe_id == vpe &&
cpu_data[cpu].tc_id != myTC)
smtc_send_ipi(cpu, SMTC_CLOCK_TICK, 0);
}
}
Regards,
Kevin K.
----- Original Message -----
From: <linux-mips@linux-mips.org>
To: <git-commits@linux-mips.org>
Sent: Friday, July 27, 2007 8:38 PM
Subject: [MIPS] SMTC: smtc_timer_broadcast ignores its arguments, make it void.
> Author: Ralf Baechle <ralf@linux-mips.org> Fri Jul 27 18:39:19 2007 +0100
> Commit: c58f4590261e0ad5f7c3e189652a61186403c35c
> Gitweb: http://www.linux-mips.org/g/linux/c58f4590
> Branch: master
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>
> ---
>
> arch/mips/kernel/smtc.c | 2 +-
> arch/mips/mips-boards/generic/time.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [MIPS] SMTC: smtc_timer_broadcast ignores its arguments, make it void.
2007-07-27 19:47 ` [MIPS] SMTC: smtc_timer_broadcast ignores its arguments, make it void Kevin D. Kissell
2007-07-27 19:47 ` Kevin D. Kissell
@ 2007-08-04 16:38 ` Ralf Baechle
1 sibling, 0 replies; 3+ messages in thread
From: Ralf Baechle @ 2007-08-04 16:38 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: linux-mips
Kevin,
On Fri, Jul 27, 2007 at 09:47:47PM +0200, Kevin D. Kissell wrote:
> The argument to smtc_timer_broadcast() is supposed to be a VPE number.
> Somewhere between the earliest prototypes and the current linux-mips.org
> tree, it got hacked up to ignore the argument and broadcast to all TCs.
> There are still configurations out there, some of which I've worked on
> pretty recently, where the platform code can be configured to either
> do global or VPE-local broadcasting of timer interrupts. While we have
> determined that it's pretty important to ensure that, in an SMTC configuration,
> having the Count registers of all VPEs in sync is important to avoid timing
> glitches, skewing the starting Compare values should help even out the load
> and reduce contention for the locks on the scheduler queues. Getting rid
> of the argument to smtc_timer_broadcast() makes that impossible. I'd
> rather see the platform timer code iterate through the configured VPEs
> and keep the argument.
>
> The most recent smtc_timer_broadcast() I've worked on looks like:
>
> void smtc_timer_broadcast(int vpe)
> {
> int cpu;
> int myTC = cpu_data[smp_processor_id()].tc_id;
>
> smtc_cpu_stats[smp_processor_id()].timerints++;
>
> for_each_online_cpu(cpu) {
> if (cpu_data[cpu].vpe_id == vpe &&
> cpu_data[cpu].tc_id != myTC)
> smtc_send_ipi(cpu, SMTC_CLOCK_TICK, 0);
> }
> }
I don't mind adding the deleted bits back.
Take the fact that this happened as a life demonstration for unused stuff
of any kind being under is under permanent threat of deletion by some
maintainer, kernel janitor or whoever else in Linux ;-)
Ralf
^ permalink raw reply [flat|nested] 3+ messages in thread