Thanks for all the input Ingo, Here's a list of all the permutations I've tried: setup Thruput CPU% from cyclesoak 2.6.21-rc5 vanilla 935 29% 2.6.21-rc5-rt5 711 50% //basically all of 1 cpu 2.6.21-rc5-rt8 733 52% 2.6.21-rc5-rt8 824 64% netperf @50 hardirq @50 softirq @50 2.6.21-rc5-rt8 937 74% netperf @51 hardirq @50 softirq @50 2.6.21-rc5-rt8 106 8% netperf @51 hardirq @49 softirq @50 2.6.21-rc5-rt8 233 14% netperf @51 hardirq @49 softirq @48 2.6.21-rc5-rt8 67 5% netperf @batch hardirq @batch softirq @batch 2.6.21-rc5-rt8 331 OFF netperf @batch hardirq @batch softirq @batch cyclesoak off Any thoughts? -Dave -------------- Original message ---------------------- From: Ingo Molnar <mingo@xxxxxxx> > > * Dave Sperry <dave_sperry@xxxxxxxx> wrote: > > > I checked the clock source and in both the vanilla and rt cases and > > they were both acpi_pm > > ok, thanks for double-checking that. > > > Here's the oprofile for my vanilla case: > > i tried your workload and i think i managed to optimize it some more: i > have uploaded the -rt8 kernel with these improvements included - could > you try it? Is there any measurable improvement relative to -rt5? > > one more thing to improve netperf performance is to do this before > running it: > > chrt -f -p 50 $$ > > this will put netperf on the same priority level as the net hardirq and > the net softirq (which both default to SCHED_FIFO:50), and should result > in a (much) reduced context-switch rate. > > Or, if networking is not latency-critical, then you could move the net > hardirq and softirq threads to SCHED_BATCH, and run netperf under > SCHED_BATCH as well, using: > > chrt -b -p 0 $$ > > and figuring out the active softirq hardirq thread PIDs and "chrt -b" > -ing them too. > > Ingo - 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
