Messages in this thread | | | Date | Tue, 14 Sep 2004 18:31:43 +0200 | From | Andrea Arcangeli <> | Subject | Re: [profile] amortize atomic hit count increments |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |