[lkml]   [2001]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: #define HZ 1024 -- negative effects?
    	I have not tried it, but I would think that setting HZ to 1024
    should make a big improvement in responsiveness.

    Currently, the time slice allocated to a standard Linux process
    is 5*HZ, or 50ms when HZ is 100. That means that you will notice
    keystrokes being echoed slowly in X when you have just one or two running
    processes, no matter how fast your CPU is, assuming these processes
    do not complete in that time. Setting HZ to 1000 should improve that
    a lot, and the cost of the extra context switches should still be quite
    small in comparison to time slice length (a 1ms time slize = 1 million
    cycles on a 1GHz processor or a maximum of 532kB of memory bus
    utilization on a PC-133 bus that transfer 8 bytes on an averge of every
    two cycles based to 5-1-1-1 memory timing).

    I would think this would be particularly noticible for internet
    service providers that offer shell accounts or VNC accounts (like
    WorkSpot and LastFoot).

    A few of other approaches to consider if one is feeling
    more ambitious are:
    1. Make the time slice size scale to the number of
    currently runnable processes (more precisely, threads)
    divided by number of CPU's. I posted something about this
    a week or two ago. This way, responsiveness is maintained,
    but people who are worried about the extra context switch
    and caching effects can rest assured that this shorter time slices
    would only happen when responsiveness would otherwise be bad.
    2. Like #1, but only shrink the time slices when at least
    one of the runnable processes is running at regular or high
    CPU priority.
    3. Have the current process give up the CPU as soon as another
    process awaiting the CPU has a higher current->count value.
    That would increase the number of context switches like
    increasing HZ by 5X (with basically the same trade-offs),
    but without increasing the number of timer interrupts.
    By itself, this is probably not worth the complexity.
    4. Similar to #3, but only switch on current->count!=0 when
    another process has just become unblocked.
    5. I haven't looked at the code closely enough yet, but I tend
    to wonder about the usefulness of having "ticks" when you have
    a real time clock and avoid unnecessary "tick" interrupts by
    just accounting based on microroseconds or something. I
    understand there may be issues of inaccuracy due to not knowing
    exactly where you are in the current RTC tick, and the cost
    of the unnecessary tick interrupts is probably pretty small.
    I mention this just for completeness.

    Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 \ / San Jose, California 95129-1034
    +1 408 261-6630 | g g d r a s i l United States of America
    fax +1 408 261-6631 "Free Software For The Rest Of Us."
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:52    [W:0.023 / U:1.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site