lkml.org 
[lkml]   [2004]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:1.883 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site