Improve idlepc detection

This issue is a collection of data aimed at improving idle pc calculation.

How idlepc suggestions are calculated:

• repeat 1000 times (not in cpu thread):
  • count instruction address
  • sleep 10ms
• for each instruction address:
  • if instruction was counted between 20 to 80 times, add it as a suggestion
  • if there are 10 suggestions, we're done

Other information:

• I'm assuming the best idlepc values point inside the scheduler function (is there a low priority idle task?)
• GNS3 0.8.6 auto detection seems to land either inside the scheduler or inside the console handling function most of the time (my intuition)
• IOS: (ref: https://github.com/flaviojs/dynamips-datasheets/blob/master/cisco/ciscoiosprogrammguide1999.pdf?raw=true)
  • uses cooperative multitasking, so there is a central scheduler that calls tasks. each task should be fast, possibly only doing part of the work in that iteration, and not worry about being interrupted
  • it's very modular, so the scheduler code is probably the same in most of the images

Questions:

• Why are the idlepc suggestions restricted to those counted between 20 and 80 times out of 1000? Is more than 80 bad?
• As I understand it, when operating systems want to idle they tell the motherboard/cpu to slow down. How is that done in the hardware we emulate and does IOS use it?

Ideas:

1. Assuming the scheduler code is almost always the same except for offsets, it's should be possible to find a pattern to identify it. (already possible, needs someone willing to look at the data around detected idlepc values)
2. A scheduler calls many different functions, maybe we can identify the scheduler by counting address+return_address combinations when a return occurs (note that library functions also have many return addresses)
3. Slow down when IOS tells it to slow down. (I need more information!!)

No files, tests, or concrete entry points are identified. Begin by locating the existing idlepc detection and suggestion-calculation implementation, then use the described sampling thresholds and scheduler assumptions to define measurable improvements for detection and IOS slowdown handling.