lkml.org 
[lkml]   [2004]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] preset loops_per_jiffy for faster booting
    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@am.sony.com
    =============================
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:0.022 / U:30.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site