On Thu, 6 Aug 2015 15:12:59 +0200 Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > * Clark Williams | 2015-08-03 13:53:26 [-0500]: > > >On Mon, 3 Aug 2015 21:36:26 +0300 > > > >Interesting. Betting that's page faults and cache filling. > > > >I don't think we want to arbitrarily pick some number of cycles for a > >"settle time" (i.e. a grace period for the application to reach steady > >state). Possibly we should add an option for that? Specify some number > >of cycles or some amount of time that where the measurement threads run > >before actual measurements start? > > > > $ cyclictest --numa -p95 -m --settle=10ms > > > >That would say "run the measurement threads for ten milliseconds before > >actually starting the measurement period". That would allow them to > >fault in and fill cache lines before starting real work. > > > >Anyone else have an opinion? > > Wouldn't you have everything in-memory after once cycle of each thread? I had to go through the timerthread() routine a couple of times to convince myself, but I think you're right. So if we wanted to discount the paging-in overhead, we could have each thread do a "dummy" pass through the timer loop (i.e. do everything but just not record the results) and then start recording measurements. I may hack together an option to try that and see what sort of results we get. Clark -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
