linux-mips
[Top] [All Lists]

Re: [PATCH v5] MIPS: Add a high resolution sched_clock() via cnt32_to_63

To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Subject: Re: [PATCH v5] MIPS: Add a high resolution sched_clock() via cnt32_to_63().
From: Ingo Molnar <mingo@elte.hu>
Date: Mon, 23 Nov 2009 18:46:08 +0100
Cc: Wu Zhangjin <wuzhangjin@gmail.com>, Ralf Baechle <ralf@linux-mips.org>, Thomas Gleixner <tglx@linutronix.de>, linux-mips@linux-mips.org, Michal Simek <monstr@monstr.eu>
In-reply-to: <4B0A8A0B.60405@ru.mvista.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <39b95d02b37cd75d275b231c31abb00aefda9078.1258972025.git.wuzhangjin@gmail.com> <4B0A8A0B.60405@ru.mvista.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.20 (2009-08-17)
* Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:

> Hello.
> 
> Wu Zhangjin wrote:
> 
> >From: Wu Zhangjin <wuzhangjin@gmail.com>
> 
> >(This v5 revision incorporates with the feedbacks from Ingo.)
> 
> >This patch adds a cnt32_to_63() and MIPS c0 count based sched_clock(),
> >which provides high resolution. and also, one new kernel option
> >(HR_SCHED_CLOCK) is added to enable/disable this sched_clock().
> 
> >Without it, the Ftrace for MIPS will give useless timestamp information.
> 
> >Because cnt32_to_63() needs to be called at least once per half period
> >to work properly, Differ from the old version, this v2 revision set up a
> >kernel timer to ensure the requirement of some MIPSs which have short c0
> >count period.
> 
> >Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
> 
> >diff --git a/arch/mips/kernel/csrc-r4k-hres.c 
> >b/arch/mips/kernel/csrc-r4k-hres.c
> >new file mode 100644
> >index 0000000..2fe8be7
> >--- /dev/null
> >+++ b/arch/mips/kernel/csrc-r4k-hres.c
> 
>    I don't think this is really good name for this file (one might 
> think that this is another implementation of clocksource instead of 
> some sched_clock() code tied to this particular clocksource), and I 
> don't think we indeed needed to separate that thing into a file of its 
> own, i.e. I'm against Ingo's suggestion in this case.

Well this patch is clearly cleaner than the previous ones - we prefer 
not to contaminate .c files with large #ifdef blocks if it can be 
avoided. (and here it can be avoided easily) YMMV.

Thanks,

        Ingo

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