[lkml]   [2003]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: scheduler interactivity: timeslice calculation seem wrong
    > I have to agree with Eric that sizing the max timeslices to fit the
    > hardware seems like a reasonable thing to do. I have little salvaged
    > systems running (well strolling would be more accurate) Linux on old
    > Pentium Classic 90-166MHz machines. I also have 3+ GHz SMP machines. I
    > have a gut feeling that the timeslices need to be longer on the slow
    > machines to allow them to get something done, that the SMP machines
    > will perform best with a different timeslice than UP of the same speed,

    scaling the timeslice with cpu_khz is a start. already there the
    smp_tune_scheduling() function that tune the load balancing based on cpu
    speed and cache size.

    the problem is that the tick timer (1000 hz) is pretty limited
    resolution in relation to cpu clock speed and most HZ-related
    calculations are correct within a limited range. that's why i was
    talking about cycles or nanoseconds resolution all the way.

    with accurate accouting we could bench the context switch time, on boot,
    and adjust timeslices based on this.. like something a 10000:1 ratio.

    > I think you also want a user tunable for throughput vs. interactive, so
    > you know what you're trying to do best.

    the kernel should have sane defauts but the user should be able to fine
    tune them. because it depends on the "intention" efficient vs
    interactivity. it's a compromise and it's not the same for server that
    desktop. middleground works but it's not the best for either.

    I've read a paper someday that measured the scheduler overhead about
    0.07% for HZ=100 and 0.7% for HZ=1000. personnally i would sacrifice a
    few percent of my cpu time to have a silky-smooth interactive feel.

    It's bizarre that my 2 GHz P4 feel slower than my old Amiga with 33Mhz.
    Throughput is greater but latency far worst.

    Eric St-Laurent

    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 13:47    [W:0.020 / U:13.232 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site