[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CADZ9YHgnss=9NrMGDgo3pO41YHQK17JZyGp=DsAUV2kVz4hSjw@mail.gmail.com>
Date: Mon, 8 Apr 2013 23:41:01 +0600
From: Rakib Mullick <rakib.mullick@...il.com>
To: Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org
Subject: [QUESTION] loops_per_jiffy calculation from smp_callin().
Hello Ingo and all,
In function arch/x86/kernel/smpboot.c::smp_callin(), we do a
calibrate_delay(), the reason behind doing this is commented as
follows:
* Get our bogomips.
* Update loops_per_jiffy in cpu_data. Previous call to
* smp_store_cpu_info() stored a value that is close but not as
* accurate as the value just calculated.
Now, if we look at the init/calibrate.c::calibrate_delay() - a percpu
variable cpu_loops_per_jiffy is used to cache up the loops_per_jiffy
value. If cpu_loop_per_jiffy value is set (which should be after first
run) then it prevents calculating new loops_per_jiffy thus the
accuracy expected from the callsite isn't getable (I'm thinking about
cpu hotpluging for few times). Is it not something that we should care
about? Is lpj value is that important to recalculate (when mostly we
read from tsc)? And, if it's important, how cpu_loop_per_jiffy is
helping?
Thanks,
Rakib.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists