Re: [PATCH] preset loops_per_jiffy for faster booting

[Tim Bird]

Adam Kropelin wrote:
> Here's an alternate patch (compile tested only) which is slightly
> simpler, slightly more flexible, and fixes a small bug in the original.

These are great improvements.  Thanks.

> The simplification centers around removing USE_PRESET_LPJ and
> interpeting a preset value of 0 as a signal to autodetect. This 
> eliminates ifdefs in the code and avoids giving magic significance 
> to the loops_per_jiffy LSb.
Yeah.  When I originally wrote it, I thought using the LSb was cute,
and avoided an extra variable.  Your way is simpler and provides
the extra feature of disabling the preset from the command line.
This, and the elimination of ifdefs is quite nice.

> Additionally, the user can always disable
> the preset by using "lpj=0" which would allow booting a kernel that
> crashes due to a bogus preset. The only problem I can think of with
> this approach is if there is a system out there so slow that lpj=0 is
> actually a valid setting.
It's hard to imagine this case, but that would merely result in
a calibration, right?  For a machine that slow, calibrating the
delay is the least of their worries. :-)

> The final change is to fix a small bug in the original patch:
> loops_per_jiffy was no longer initialized each time calibrate_delay()
> was invoked. This is potentially an issue on SMP systems since
> calibrate_delay() will be invoked for each CPU. One related thing to
> keep in mind is that on an SMP system, using an lpj preset will result
> in the same lpj setting on each CPU. On sane systems this shouldn't be
> a problem, but if there's a machine out there with unequal CPUs it will
> be a problem. Perhaps this is worth mentioning in the help text as well.
I hadn't considered this.  (Too much "embedded" on the brain.)
By help text, do you mean the config text, or something on the wiki page,
or some other file (in Documentation?).

On the subject of help text, is there a Documentation file I should modify
or someone I should notify about the addition of a new kernel command line
option?

> While we're on the topic: Should FASTBOOT perhaps depend on EMBEDDED? I
> can imagine a user with a massively MP system perhaps finding this
> option useful, so maybe not.

I had it there originally, then changed my mind.  I know some server
guys are interested in fastboot.  This particular change might not
be that interesting, but some of the other changes we are thinking of
might not be specific to just embedded.

I will do some runtime testing on your patch, but I probably won't be
able to report back until Monday.

Thanks very much!
  -- Tim

=============================
Tim Bird
Architecture Group Co-Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
E-mail: tim.bird@xxxxxxxxxxx
=============================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/