* Ran Shalit <ranshalit@xxxxxxxxx> [150801 11:34]: > Hi , > > I've accidently omitted linux-omap in last message, so please here it is again: > > I think that if someone here understand cpuidle it may lead me to a solution... > > 1. I'm using TI's kernel 2.6.37 > http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/ Hmm that's not the TI kernel, that's where we keep the omap patches heading to the mainline kernel tree :) > 2. I think it is related to the menu governer who decides on c-state change. > But I'm not sure what and how I need to change so that the ethernet > test for small windows will have same performance as without PM. > 3. I see that the performace as tested with iperf has the same > performace results with large packets but with small packets (smaller > then 2000 bytes) there is high degredation (only if cpuidle is used) > I also see that the counter for C3(core inactive - not retention yet) > state is icremented with the small packet test. > Does anyone have any idea why the small packet test results in > entering (and exit ) several times the core inactive state? Why does > not it happen with big packet test? And what can I do to overcome this > degredation? > 4. Can anyone try to run iperf with small packet (2000 bytes or below) > for checking ethernet bandwidth? And then compare this with results in > kernel without power management support? If you don't have anything blocking deeper idle states from the Ethernet controller then the hardware can start entering deeper idle states. I can see this happening when transferring data with DMA over Ethernet especially if you have an external Ethernet controller connected to GPMC. If you cannot rely on the hardware IDLEST bits to keep the system from entering deeper idle states, then you have to use the runtime PM API to do it somehow. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html