Re: [profile] amortize atomic hit count increments

Andrea Arcangeli
2004-09-14T17:02:47Z

On Tue, Sep 14, 2004 at 09:16:48AM -0700, Jesse Barnes wrote:
> the readprofile times, I'd say per-cpu would be the way to go just because it
> retains the simplicity of the current approach while allowing it to work on
> large machines (as well as limiting the performance impact of builtin
> profiling in general). wli's approach seems like a reasonable tradeoff
> though, assuming what you suggest doesn't work.

per-cpu certainly sounds simple enough conceptually, so if you can
notice any slowdown even with idle loop ruled out, per-cpu is sure
better.

This bouncing is likely to hurt smaller SMP too (but once the cpu is
idle normally it's not a too bad thing since it only hurted reschedule
latency, since we remain stuck in the timer irq for a bit longer than we
should), but duplicating the ram of the array there doesn't look as nice
as it would be on the altix, not all SMP have tons of ram. So an
intermediate solution for this problem still sound worthwhile for the
normal smp case.