Just my guess......
On Tue, Apr 14, 2009 at 10:58 PM, Sol Kavy <skavy@xxxxxxxxxx> wrote:
>
> I have discovered why other architectures do not have the same problem. The back trace indicates a real defect (i.e. deadlock) in the generic code.
>
> Most architectures override sched_clock() with their own version. Kernel/sched_clock.c:38 is a weak alias that will be overridden if an arch directory supplies its own.
>
> Most of the arch directories provide an implementation that directly access the jiffies_64 variable "without" acquiring the xtime_lock.
>
> Some of the implementations provide a "poor" implementation in that the value of the jiffies_64 during a 32 rollover is not taken into account. If sched_clock() is to be called while holding xtime_lock, the core implementation should be modified not to call get_jiffies_64() (which requires the xlock) but to use something like the following:
>
> unsigned long long sched_clock(void)
> {
> unsigned long long my_jiffies;
> unsigned long jiffies_top;
> unsigned long jiffies_bottom;
>
> do {
> jiffies_top = jiffies_64 >> 32;
> jiffies_bottom = jiffies_64 & 0xffffffff;
in general this type of operation is only done when u are in 32bit
mode. In 64bit mode, u can do it in ONE atomic assembly
instruction.....so no locking needed.
> } while(unlikely(jiffies_top != (unsigned long)(jiffies_64 >> 32)));
>
> my_jiffies = ((unsigned long long)jiffies_top << 32) | (jiffies_bottom);
> return (my_jiffies - INITIAL_JIFFIES) * (NSEC_PER_SEC / HZ);
> }
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
