linux-mips
[Top] [All Lists]

Re: Extreme system overhead on large IP27

To: anemo@mba.ocn.ne.jp
Subject: Re: Extreme system overhead on large IP27
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 26 Oct 2006 13:05:52 +0900 (JST)
Cc: creideiki+linux-mips@ferretporn.se, ralf@linux-mips.org, linux-mips@linux-mips.org
In-reply-to: <20061025.174504.71086461.nemoto@toshiba-tops.co.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20061024140614.GB27800@linux-mips.org> <6285.136.163.203.3.1161704681.squirrel@www.ferretporn.se> <20061025.174504.71086461.nemoto@toshiba-tops.co.jp>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 25 Oct 2006 17:45:04 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> 
wrote:
> > 2. Timekeeping is broken. The clock in /proc/driver/rtc seems correct, but
> > the system clock advances at about 1/16 of real time.
> 
> Is this problem still happen if you disabled CONFIG_OPROFILE ?

I think I found the problem at last.

static struct clocksource clocksource_mips = {
        .name           = "MIPS",
        .rating         = 250,
        .read           = read_mips_hpt,
        .shift          = 24,
        .is_continuous  = 1,
};

This shift value is too large for ip27 HPT (1.25MHz).

        temp = (u64) NSEC_PER_SEC << clocksource_mips.shift;
        do_div(temp, mips_hpt_frequency);
        clocksource_mips.mult = (unsigned)temp;

If mips_hpt_frequency is less than 0x1000000 (16777216), temp would be
larger than possible 32bit value.  I'll cook a patch later but until
then you can use lesser shift value, for example, 20.

---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>