On 23 November 2015 at 17:44, Maxim Uvarov <[email protected]> wrote: > I think work for ODP PM can be focused on following: > > Let's imagine example 10Gb link can be processes on 4 cores on about 100% > cpu load on top speed. Or it can be > on 8 cores with 50% load on top speed. Or 8 cores and 100% cpu load on half > core speed. Or 2 cores on top speed > and other of half speed. So question is which state is more power efficient > and supports long live for hardware > (less fan rotating, less heating and etc.)? (Plus add Bit-Little cores > question). >
Thinking in this way is good, but it is too complicated for now, even the kernel power management framework doesn't have such feature till now, eg for cpufreq, for most platforms kernel usually scale freq for all cores at same time. Recently Linaro Power Management Working Group is working for such feature for big.LITTLE, it is a hard work. Your idea need a "power data array" for each state, and it varies from Soc to Soc. Currently my imagination is simple: suppose we are running "odp_generator -m r", if no packets arrives, or only a few packets, cpus should run at lower or lowest speed in stead of at highest speed all time, thus the load can be a throttle to scale the cpu clock speed. > Logically right answer depends on platform and application itself. But > application can give hints to the platform which > mode it needs: power saving or top speed. Or even switch cpu to top speed > mode when processing some heavy function. > > For NICs dpdk looks at rx pktio queue and changes C state if queue is close > to full: > http://dpdk.org/doc/guides/prog_guide/power_man.html > > SoCs should be a little bit complex and should allow to change clk for > different things. It might be better to talk with our HW vendors > and ask what they can do. I.e. what do they need from API point of view to > be more efficient. > > Best regards, > Maxim. > > > On 11/20/2015 23:56, Bill Fischofer wrote: >> >> From an ODP application standpoint there are several factors to consider. >> First, power management if fundamentally a concern of the ODP implementation >> more than then application. The main way a data plane application should >> manage its workload is by creating and terminating worker threads (probably >> as instructed by the control/management plane which is managing the overall >> workload). With isolated cores, if there is no thread to run this is an >> obvious candidate for the core to enter a low-power state until such time as >> a thread wants to make use of it. There's no need for an explicit API >> here--the fact that the thread isolated on that core is terminating should >> be sufficient. >> >> Beyond this, the proper place for these considerations are in the >> implementation of the odp scheduler and to a lesser degree the various >> synchronizers. When a thread calls odp_schedule() the scheduler knows >> whether it has events to dispatch. If none are available, then it would be >> reasonable for the scheduler to consider informing the underlying OS that it >> this thread/core is idle and thus eligible for power management. There's >> always a tradeoff here between energy savings and responsiveness to wakeups >> on new events arriving. Such tradeoffs are again the domain of the >> control/management plane. >> >> The advantage of this approach is that ODP itself becomes independent of >> whether it is running in a real or virtual machine environment, which is >> important as NFV becomes more of the norm. >> >> On Fri, Nov 20, 2015 at 8:51 AM, Hongbo Zhang <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi guys, >> https://projects.linaro.org/browse/ODP-242 >> I'd like to discuss with you about this issue, hope you can make it >> clear about the real requirement, give suggestions and make a >> coincident conclusion before we go further on a wrong way. >> >> First question is what is the original requirement? "core shutdown and >> startup" means cpudile or hot plug? or no specific requirement but >> just want to save the power? >> >> I think when odp wants to control the power consumption, a >> precondition should be isolation or similar, eg no other else share >> the cpu with odp, then when odp load becomes low it can start any >> method to save power. >> >> Basically three mechanisms can be used for saving power, >> cpudile,cpufreq and hot plug. >> Usually cpuidle is done by kernel, if we want to try it in user space >> that will be too complicated to implement, so I give it up firstly. >> The cpufreq and hot plug, from my point of view, can be tried. But a >> precondition is we know that the cpu isn't fully loaded. While the odp >> is always polling, so from legacy point of view the cpu load should be >> 100%, in fact the cpu may not handle packets all the time, sometimes >> it polls nothing. So we need to create a function to get statistics of >> the "real load". >> >> Then further questions, should we create such a statistics interface? >> how is the feasibility? by monitoring the cpu time, or by monitoring >> the queues? or others? >> (if we put every items in queues, then queues empty means nothing >> to do?) >> >> I've already had some comments on that Jira link, and Ivan gave his >> valuable comments too, do you have further comments/suggestions? you >> can leave them here, or let's discuss at the meeting: >> https://collaborate.linaro.org/display/LNG/2015-11-23+ODP+ARCH >> Hope we get coincident idea at meeting. >> _______________________________________________ >> lng-odp mailing list >> [email protected] <mailto:[email protected]> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
