Em 13/03/2009, às 07:28, Christian Packmann <Christian.Packmann@xxxxxx> escreveu:
André Braga - 2009-03-13 01:53 :On the other hand, as far as cycles and IPS are concerned, a milisecond on a 200MHz is a *lot* different than a milisecond on a 3GHz CPU. Not taking this into consideration if you boost thread priorities based on consumed quantum is a *bad* idea.Clock frequency doesn't matter in itself. Average IPC (instruction per cycle) times clock frequency does.
Sneaky 'S' key got beneath my finger unnoticed. Of course I meant IPC, not IPS :P
If something like your idea is implemented, the clock frequencies need to be normalized against the CPU architecture. Not only on x86, but other CPU architectures as well; ARM also has in-order and out- of-order designs, even though the IPC doen't vary as wildly as it does on x86.
A calibration loop with a *good* mix of instructions during CPU initialisation should suffice, no?
I can think of two approaches for this:1. the ability to set CPU affinity for a thread, so that an application developer can select the CPUs/thread layout on a CPU himself. 2. adding a flag to thread spawning routines which indicate if a thread is memory-bound, CPU-bound or general (i.e., a mixture of both).
I don't know the first thing about performance counters, except that they exist. With this disclaimer in place, can't they be used to derive the behaviour of a thread in this regard? Like if it spent a lot of time waiting for memory or if it actually taxed the CPU with calculations.
If the threads of a specific application could benefit from a peculiar thread/CPU affinity because some threads share lots of data while others don't, fixed CPU affinity could optimize the performance, which the OS never can do having to look at threads as "black boxes".
Sure. Still, you can't completely avoid cache trashing if your application isn't the sole running app in the system. :)
I've considered a "pin this CPU to this thread" (as opposed to the usual other-way-around) option to the affinity settings, but it seems that Axel didn't like this and wanted the scheduler to be more automagical in this regard. The default behaviour WILL be to run a thread on the same processor it ran less, to spawn new treads on the lesser loaded processors, and to consider load delta between the various processors and topology (buses, shared caches, performance score (for the AMP case)) as well when balancing load.
Oh, and fixing CPU affinity would also allow me for writing proper benchmarking tools without having to worry about core hopping, so I'm not quite neutral in this matter. ;-)
Which is why feedback is important. What kind of (behaviour- influencing, as in B_SAME_PACKAGE_BUT_AVOID_LOGICAL or what have you; not just processor masking) flags would you like to be there when you set affinity for threads on a team?
