Re: [profile] amortize atomic hit count increments

[William Lee Irwin III]

On Tue, Sep 14, 2004 at 06:31:43PM +0200, Andrea Arcangeli wrote:
> 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.

Could you clarify whether you deem the per-cpu hashtable -based
amortization acceptable or whether this refers to per-cpu profile
buffers? I devised the hashtables to address space footprint concerns,
so I'm in a pickle if both have pending objections.

Thanks.


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/