Re: [PATCH] x86: enable preemption in delay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Sun, 25 May 2008, Pavel Machek wrote:
> > +		if (unlikely(cpu != smp_processor_id())) {
> > +			if (loops <= TSC_MIGRATE_COUNT)
> > +				break;
> > +			cpu = smp_processor_id();
> > +			rdtscl(bclock);
> > +			loops -= TSC_MIGRATE_COUNT;
> > +		} else {
> > +			rdtscl(now);
> > +			if ((now - bclock) >= loops)
> > +				break;
> > +			loops -= (now - bclock);
> > +			bclock = now;
>
> What happens with different cpus running on different frequencies...?
> Cpufreq?

It's not even protected with the old code.

inline void __const_udelay(unsigned long xloops)
{
	__delay(((xloops * HZ *
		cpu_data(raw_smp_processor_id()).loops_per_jiffy) >> 32) + 1);
}

Here it calculates the loops_per_jiffy for the CPU and calls into __delay.
But it can easily be preempted here and the delay could run on another
CPU.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux