On Mon, Aug 3, 2015 at 4:21 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * 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 Hi, I am using GPMC with smsc911x controller. If I understand you correctly, I can overcome this, but asking the hardware not get into inactive state. I actully need that the code won't get into inactive state (I don't think that anyelse is inactive, except the core - this is C3 state). The problem with this approach is that I'm not sure I can determine when to decide "turn cpuidle off" and when to decide "turn cpuidle on". I thought that if there is a way to ask the governer (in tickless kernel, it is menu governer), to wait for a longer time, before deciding to get into sleep. I think that if it waits longer time, it will see that there are tasks to do (small packets in iperf test), and will not enter sleep state. Is that possible ? Is there any parameter in governer which control this ? Thank you, Ran -- 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
