Re: boot-time slowdown for measure_migration_cost

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In-Reply-To: <[email protected]>

On Mon, 30 Jan 2006, Tony Luck wrote:

> Might it be wise to see whether the 2% variation that I saw can be
> repeated on some other architecture?  Bjorn's initial post was just
> questioning whether we need to spend this much time during boot to acquire
> this data.  Now we have *one* data point that on an ia64 with four cpus
> with 9MB cache in a single domain that we can speed the calculation by
> a factor of three with only a 2% loss of accuracy.  Can someone else try
> this patch and post the before/after values for migration_cost from dmesg?

Before:

messages.1:Jan 24 01:19:45 d2 kernel: [    6.377117] migration_cost=9352
messages.1:Jan 27 21:07:55 d2 kernel: [    6.384871] migration_cost=9329
messages.1:Jan 28 11:00:32 d2 kernel: [    6.384215] migration_cost=9338
messages.1:Jan 28 12:55:03 d2 kernel: [    6.389189] migration_cost=9364


After:

messages:Jan 31 07:55:07 d2 kernel: [    1.859359] migration_cost=9274


This was on a dual PII Xeon with 2MB L2 cache.  About 3.5x as fast and
only 1% change.

Maybe the default could be to run the quick test with an option to run the
more-accurate one?

-- 
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux