Messages in this thread | | | Date | Tue, 15 Jun 2010 12:37:05 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] Fix a race in pid generation that causes pids to be reused immediately. |
| |
On Tue, 15 Jun 2010 16:35:52 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> > I suspect sched_clock.c might be generating fair amounts of code which > > UP builds don't need. > > Only sched_clock_remote() and its caller, something like the below, not > much code.. > > UP machines can still have utterly sucky TSC, although the > inter-cpu-drift thing isn't much of an issue ;-) > > --- > kernel/sched_clock.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/kernel/sched_clock.c b/kernel/sched_clock.c > index 52f1a14..7ff5b56 100644 > --- a/kernel/sched_clock.c > +++ b/kernel/sched_clock.c > @@ -170,6 +170,7 @@ again: > return clock; > } > > +#ifdef CONFIG_SMP > static u64 sched_clock_remote(struct sched_clock_data *scd) > { > struct sched_clock_data *my_scd = this_scd(); > @@ -205,6 +206,7 @@ again: > > return val; > } > +#endif > > /* > * Similar to cpu_clock(), but requires local IRQs to be disabled. > @@ -226,9 +228,11 @@ u64 sched_clock_cpu(int cpu) > > scd = cpu_sdc(cpu); > > +#ifdef CONFIG_SMP > if (cpu != smp_processor_id()) > clock = sched_clock_remote(scd); > else > +#endif > clock = sched_clock_local(scd); > > return clock;
hm, OK, I was actually looking at sched_clock_local() at the time. Can clocks go backwards on UP hardware? What breaks if we do #define sched_clock_local sched_clock?
I've mentioned this before, but sched_clock.c is really opaque - it would be a formidable task for anyone to get in there and work on the code if they hadn't already been working on it for years.
| |