The initcall_debug code access the tv64 member of ktime. This won't work
correctly for large deltas on platforms that don't use the scalar ktime
implementation.
Signed-off-by: Will Newton <[email protected]>
---
init/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/init/main.c b/init/main.c
index 7e117a2..0eff42a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -718,7 +718,7 @@ int do_one_initcall(initcall_t fn)
if (initcall_debug) {
it.rettime = ktime_get();
delta = ktime_sub(it.rettime, it.calltime);
- it.duration = (unsigned long long) delta.tv64 >> 10;
+ it.duration = (unsigned long long) ktime_to_ns(delta) >> 10;
printk("initcall %pF returned %d after %Ld usecs\n", fn,
it.result, it.duration);
trace_boot(&it, fn);
--
1.5.5.2
Will Newton wrote:
> The initcall_debug code access the tv64 member of ktime. This won't work
> correctly for large deltas on platforms that don't use the scalar ktime
> implementation.
In principle I see no problem with this. But as a matter of
practice it may be overkill.
How big does the delta have to be for this to be a problem?
And how much overhead does ktime_to_ns() add?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
On Thu, Nov 20, 2008 at 5:39 PM, Tim Bird <[email protected]> wrote:
> Will Newton wrote:
>> The initcall_debug code access the tv64 member of ktime. This won't work
>> correctly for large deltas on platforms that don't use the scalar ktime
>> implementation.
>
> In principle I see no problem with this. But as a matter of
> practice it may be overkill.
Possibly, but it makes the code clearer I think.
> How big does the delta have to be for this to be a problem?
> And how much overhead does ktime_to_ns() add?
Deltas over a second will be incorrect. I have serial8250_init taking
8 seconds at the moment, so that isn't unheard of.
On scalar ktime architectures it should be zero, on others a multiply
and an add (it's an inline). I wouldn't call it a fast path though.
> -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Corporation of America
> =============================
>
>
Will Newton wrote:
> On Thu, Nov 20, 2008 at 5:39 PM, Tim Bird <[email protected]> wrote:
>> Will Newton wrote:
>>> The initcall_debug code access the tv64 member of ktime. This won't work
>>> correctly for large deltas on platforms that don't use the scalar ktime
>>> implementation.
>> In principle I see no problem with this. But as a matter of
>> practice it may be overkill.
>
> Possibly, but it makes the code clearer I think.
>
>> How big does the delta have to be for this to be a problem?
>> And how much overhead does ktime_to_ns() add?
>
> Deltas over a second will be incorrect.
OK. Good fix, then.
> I have serial8250_init taking
> 8 seconds at the moment, so that isn't unheard of.
This is likely the result of the emission of all
previously queued printks which occurs during serial8250_init()
(as a side effect of finally initializing the console).
I see this kind of long delay all the time.
If the 8 seconds is a bother, you might want
to use 'quiet' on the kernel command line.
I suspect you've already seen this page, but for future
readers of this thread, there's info on this at:
http://elinux.org/Disable_Console
> On scalar ktime architectures it should be zero, on others a multiply
> and an add (it's an inline). I wouldn't call it a fast path though.
OK. You have my ACK.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================