On Mon, 2008-02-04 at 14:33 -0600, Tom Harper wrote: > Another fact not well understood is the magnitude of performance > degradation when a cache miss occurs. Bob Rogers at the last SHARE > mentioned that while cache misses in first and second-level caches were > not too bad, cache misses that resulted in actual references to memory > could be as much as 600 times slower. His comment: It's almost like > doing an I/O to reference main storage compared to getting a hit in > first-level cache.
With the presumably imminent announcement of a quad-core based z9 replacement, I wonder if Bob has been musing more on this of late. Especially if they release CECs that are full of these things - 64, 128, ... think of a multiple of 2 (1024 ?? woohoo) . No doubt packaged as "books". Sounds horribly NUMA. The hipervisors will need to be at pains to redispatch guests on same engine(s) where possible - probably do already. With lots of engines maybe it could (soft) dedicate engines to guests - mmmm; z/OS in partitions sounds a better candidate for this than z/VM juggling masses of Linux guests. But of course the hipervisor itself has to run somewhere - causing the same (cache-flush) problem. Why isn't it run on a spare - if/when they are available, and stay "out of the way" ???. With that in place, why can't the guest "optimise" its dispatch algorithms to dispatch tasks on the same logical (aka physical) engine to attempt to benefit from the data (hopefully) still in the lines. Linux goes out of it's way to attempt this - more so in NUMA environments. Shane... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
