Reply to post:

Fujitsu: Why we chose 64-bit ARM over SPARC for our exascale super


"Since most businesses, of a size suitable to have someone in IT working for them, has moved to a virtualized infrastructure then their cores should not be sitting 99% idle or they haven't sized their system very well."

If you run VTune on the bare metal you will see lots of expensive cache misses where the CPU is sat twiddling it's thumbs waiting for memory to catch up. In old school super-computing this wasn't an issue because the core clock speeds were similar to the *random access* latency of the memory subsystem (and the applications + OS were tuned to maximize page/cache locality.

"Virtualized Infrastructure" workloads are actually particularly rough on caches and TLBs, their memory access patterns are much more random - they are nowhere near as kind to the memory subsystems as a well tuned HPC workload. Consequently the cores spend a lot of time idle waiting for memory to catch up, and in this scenario the OS will report the CPU being 100% busy - if you want to find out how much of that 100% busy is spent waiting for memory you'll need to run VTune or something like that. I wish these kind of stats were more readily available to end-users and sys-admins - the CPU occupancy figures are pretty much meaningless these days - they just tell you when the run queue is exhausted and nothing useful about how busy the system really is. :)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon