Re: IRQ Tracing Problem in Linux 2.6.28 Kernel

[Peter Teoh <htmldeveloper@gmail.com>]

Just my guess......

On Tue, Apr 14, 2009 at 10:58 PM, Sol Kavy <skavy@ubicom.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs