[lkml]   [2000]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Auto-Adaptive scheduler - Final chapter ( the numbers ) ...
    Davide Libenzi wrote:

    > Thursday, January 27, 2000 6:10 PM
    > Horst von Brand <> wrote :
    > > As was said here time and again: This is ridiculously unrealistic. Your
    > > benchmark plus whatever scheduler you use fits in the smallest cache. Use
    > > some code that is some 2 or 3Kb at least between schedules, and run
    > > _different_ code each time. I'd bet you see quite different numbers that
    > way.
    > These are my words in Larry answer :
    > This is a pure switching time test.
    > It is a _real_ switching test, that can be used to test switching times
    > under _certain_
    > RQ loads :
    > vmstat of a "lat_ctx -s 0 20" give no more than 5-6 tasks in RQ
    > vmstat of a "threads 20 xx" give always an RQ = 20 ( with no need of cost
    > compensation )
    > Now, as even my sister ( that works in business ) can realize this code is
    > stored entirely in cache, and the write to the counter is onto the process
    > stack.
    > I _want_ this behaviour coz I _want_ a measure of clean switching times by
    > keeping
    > cache issues ot of the test.
    > Anyway adding a cache footprint into the two cases will add a constant term
    > that minimize
    > even more the percent result.

    I really do urge you to go to a bookstore, find a recent book on computer
    architecture, and try to find out how a modern machine works. Larry
    recommended a book. Maybe you should try that one.

    Almost any modern CPU has at least two levels of cache. What people are
    refering when criticising the validity of your tests is the need to overflow
    the bounds of the small level 1 I and D caches, and force loading from at
    least the level 2 cache. Your test is too small scale to do that, and it makes
    it totally meaningless.

    If you don't understand why a modern CPU has multiple levels of cache (even on
    a single chip design like the Celeron); if you don't understand their relative
    performance, latencies, loading and storing behaviour, and why there are
    separate I and D caches; if you don't understand how SDRAM and DDR SDRAM work,
    why RDRAM doesn't work well, and the latency patterns of these parts; if you
    don't understand the access and speed patterns of I/O busses, like PCI; and if
    you don't understand the trends in the relative performance of these parts and
    the CPU core over the next 2 to 5 years you really cannot contribute much to
    OS design.

    "Ah!", you might say, "but I'm not an electronics guy". It really doesn't
    matter. Computer architecture design has almost nothing to do with
    electronics, and almost everything to do with simple topology. You can learn
    about the key constraints that electronic and mechanical design impose in a
    couple of hours. The rest is _all_ about topology. You only need to understand
    electronic design at the level of "A PCB can realistically have 6 to 8 layers.
    Two are taken by power, so you 4 to 6 layers to work with in connecting
    everything together. The refractive index of epoxy-glass boards means signals
    travel at about 200mm/ns across the board. Current IC packaging constraints
    are that you can have 40 pins cheaply, 400-500 pins aren't too expensive, and
    you can go up to 1000-1500 on a really high value part.". Of course, the list
    is rather longer than this, involving the performance of core logic, and
    memory cells, but you only need to understand what the elements can achieve.
    After that, computer architecture is about chaining these elements in the most
    effective way to form a system - its all topology.

    An OS is a hardware manager. If you have ever worked on an engineering project
    whether the manager was not well versed in the technologies of the project you
    will understand what happens when people with nothing more than software
    knowledge design an OS! In fact, the need to understand the hardware is a
    growing one. As machine progress to more to more complex designs, with SMP,
    several layers of cache, more complex DRAM architectures, and so on, the
    machines are becoming less homogenous. Even application designers now need a
    much greater understanding of the machines they use, to grasp why their
    program behaves the way it does.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.023 / U:1.408 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site