> Thursday, January 27, 2000 6:10 PM> Horst von Brand <vonbrand@pincoya.inf.utfsm.cl> 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 :>> <DONTSPLITTHIS>> 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.> </DONTSPLITTHIS>>> 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 computerarchitecture, and try to find out how a modern machine works. Larryrecommended a book. Maybe you should try that one.

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

If you don't understand why a modern CPU has multiple levels of cache (even ona single chip design like the Celeron); if you don't understand their relativeperformance, latencies, loading and storing behaviour, and why there areseparate 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 youdon't understand the access and speed patterns of I/O busses, like PCI; and ifyou don't understand the trends in the relative performance of these parts andthe CPU core over the next 2 to 5 years you really cannot contribute much toOS design.

"Ah!", you might say, "but I'm not an electronics guy". It really doesn'tmatter. Computer architecture design has almost nothing to do withelectronics, and almost everything to do with simple topology. You can learnabout the key constraints that electronic and mechanical design impose in acouple of hours. The rest is _all_ about topology. You only need to understandelectronic 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 connectingeverything together. The refractive index of epoxy-glass boards means signalstravel at about 200mm/ns across the board. Current IC packaging constraintsare that you can have 40 pins cheaply, 400-500 pins aren't too expensive, andyou can go up to 1000-1500 on a really high value part.". Of course, the listis rather longer than this, involving the performance of core logic, andmemory cells, but you only need to understand what the elements can achieve.After that, computer architecture is about chaining these elements in the mosteffective way to form a system - its all topology.

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

Steve

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