[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090417164918.GK8253@elte.hu>
Date: Fri, 17 Apr 2009 18:49:18 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Christoph Lameter <cl@...ux.com>, linux-kernel@...r.kernel.org
Subject: Re: Scheduler regression: Too frequent timer interrupts(?)
* Peter Zijlstra <peterz@...radead.org> wrote:
> > > Is the overhead 1%? 2%? 0.5%? And how did it change from
> > > 2.6.22 onwards? Did it go up by 0.1%, from 1% to 1.1%? Or did
> > > the average go down by 0.05%, while increasing the spread of
> > > events (thus fooling your cutoff)?
> >
> > As you see in the diagrams provided there is a 4 fold increase
> > in the number of interrupts >1usecs when going from 2.6.22 to
> > 2.6.23. How would you measure the overhead? Time spent in the
> > OS? Disturbance of the caches by the OS that cause the
> > application to have to refetch data from Ram?
>
> You could for example run an NMI profiler at 10000 Hz and collect
> samples. Or use PMU hardware to collect numbers
it's even simpler than that: use a user-space loop and an alert()
based signal-handler triggered measurement to count the number of
loops user-space can execute, per second.
Such measurements can very easily be made much more precise than
0.1%, and in a tight loop there's basically no caching issues - it
measures pure 'cycles left for user-space' performance.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists