lkml.org 
[lkml]   [1999]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Scheduler set to 1000Hz
    Date
    From
    MOLNAR Ingo <mingo@chiara.csoma.elte.hu> wrote thus:
    (speaking of 'jiffies' scaled values in /proc/ and elsewere..)
    > 'Hz' has a physical definition. The Linux HZ constant just says how many
    > timer interrupts per second should occur. The requirement is to never let
    > this (arbitrary) constant show up, but to have all API components use the
    > 'real-world' definition of time.

    That would be ideal, but what will you do, when your
    applications using current interface need then be
    changed. A flag-day ?

    > > In this case the deprecated sysconf(_SC_CLK_TCK) would be THE answer
    > > to solve the problems that ps/top/et.al. have.
    >
    > not at all. The problem is that /proc/<pid>/stat (and other kernel
    > interfaces) export values that are dependent on the kernel-internal HZ
    > definition. They should export 'natural' units like nanoseconds or
    > microseconds, this solves the problem once for all, makes binary data
    > files exchangable between different-HZ Linux boxes, etc.

    Remember, we have binary interfaces, and "ASCII" ones.
    For *binary* interfaces usage of structures with nanoseconds
    and seconds would be best (assuming at least 32 bits for
    both fields), for ASCII ones I would present times as:
    12345.98765
    placing the "decimal point" to mark how the time is in
    seconds, and decimal franctions of it.

    Presenting the fractions would be challening, though.
    In order of not to loose accuracy in jiffies fraction,
    you will want to present the printout with enough digits,
    but how you determine the needed scalers ?

    #if HZ <= 1000 /* 50, 60, 1000, whatever */
    # define HZ_SCALER 1000
    # define HZ_SCALER_DIGITS "3"
    #elsif HZ <= 10000 /* 1024, etc */
    # define HZ_SCALER 10000
    # define HZ_SCALER_DIGITS "4"
    #elsif HZ <= 100000 /* tock, tock, are you mad ? */
    # define HZ_SCALER 100000
    # define HZ_SCALER_DIGITS "5"
    #else /* HZ > 100 000 ---> you are mad! */
    # warning "HZ_SCALER may be too low, but your HZ is way too high!"
    # define HZ_SCALER 1000000
    # define HZ_SCALER_DIGITS "6"
    #endif

    sprintf(buf, "%d.%0"HZ_SCALER_DIGITS"d", jiffies / HZ,
    ((jiffies % HZ)*HZ_SCALER+HZ/2)/HZ);


    with back-converting that value to HZ base my test
    program (integer math all the way) kept all the time
    the difference in between the original "jiffies", and
    the back-coverted value in round zero.

    Same algorithm can be used to translate 'jiffies'
    things to 'nanoseconds', but beware 32-bit overflow
    dangers... Perhaps for that reason doing it in
    'microseconds' would be sensible (up to HZ=2147,
    maybe even up to HZ=4294)

    Looking at those expressions above I see well, why
    DEC UNIX, and thus Linux/Alpha uses HZ value of
    1024, and *not* 1000 ! In fact when changeing to
    the scaled interfaces, I would suggest refraining
    from using any other HZ values than powers of two:
    16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192.

    > -- mingo

    /Matti Aarnio <matti.aarnio@sonera.fi>

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:49    [W:3.226 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site