Messages in this thread | | | Date | Sat, 6 Dec 2008 02:23:54 +0100 | From | Mikael Pettersson <> | Subject | Re: [patch 0/3] [Announcement] Performance Counters for Linux |
| |
Paul Mackerras writes: > Furthermore, since your generic code doesn't know anything about the > constraints and thinks it can just add any counter to any task at any > time
This observation alone makes this proposal a non-starter. Counters are not independent. Even on x86. Never have been.
If you want to fix something, here's one: - Make the decision whether to schedule task t on processor p a function of what other set of tasks T are currently on processor p.
The issue is that some performance counter events aren't thread local, e.g. Nehalem uncore stuff and similar HW crap in AMD northbridge events and everything P4. So while one task t1 is running it's also reserving off-thread resources R, making those resources unavailable for other tasks T.
(If you want a simpler metaphor, imagine a multi-threaded or multi-core processor package having only a single floating-point unit. How would you handle that in the scheduler? There are performance counter events from both Intel and AMD that pose the same challenge.)
I "solved" that in perfctr for P4 by enforcing affinity constraints, but surely the scheduler could be smarter?
| |