linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* power states transitions
@ 2015-11-22 15:58 Ran Shalit
  2015-11-25 18:50 ` Tony Lindgren
  0 siblings, 1 reply; 4+ messages in thread
From: Ran Shalit @ 2015-11-22 15:58 UTC (permalink / raw)
  To: Linux OMAP Mailing List, linux-pm

Hello,

I have stranhe behaviour in which even when there is no activity in
serial port, the retention counter is keep incremented all these time,
as if the cpu gets in and out of retention periodically.
I would expect the cpu to get into retention mode, when there is no
activity and stay in that state.
What can cause such behaviour ? Is it because some background process ?
These are the processes I see using ps command :

~ # ps
  PID USER       VSZ STAT COMMAND
    1 root      2088 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW   [kworker/u:0]
    6 root         0 SW<  [khelper]
    7 root         0 SW   [irq/72-serial i]
    8 root         0 SW   [irq/73-serial i]
    9 root         0 SW   [irq/74-serial i]
   10 root         0 SW   [sync_supers]
   11 root         0 SW   [bdi-default]
   12 root         0 SW<  [kblockd]
   13 root         0 SW   [khubd]
   14 root         0 SW   [kseriod]
   15 root         0 SW<  [twl4030-irqchip]
   16 root         0 SW   [twl4030-irq]
   17 root         0 SW   [irq/378-twl4030]
   18 root         0 SW   [kworker/u:1]
   19 root         0 SW<  [musb-hdrc.0]
   20 root         0 SW<  [kconservative]
   21 root         0 SW   [kswapd0]
   22 root         0 SW<  [aio]
   23 root         0 SW<  [crypto]
   29 root         0 SW   [mtdblock0]
   30 root         0 SW   [mtdblock1]
   31 root         0 SW   [mtdblock2]
   32 root         0 SW   [mtdblock3]
   33 root         0 SW   [mtdblock4]
   34 root         0 SW   [mtdblock5]
   35 root         0 SW   [mtdblock6]
   36 root         0 SW   [mtdblock7]
   37 root         0 SW   [mtdblock8]
   38 root         0 SW   [mtdblock9]
   41 root         0 SW   [kworker/0:1]
   42 root         0 SW<  [kondemand]
   43 root         0 SWN  [jffs2_gcd_mtd5]
   46 root         0 SWN  [jffs2_gcd_mtd6]
   47 root         0 SWN  [jffs2_gcd_mtd8]
   48 root         0 SWN  [jffs2_gcd_mtd7]
   71 root      2364 S    /usr/sbin/inetd
   74 root      2092 S    -/bin/sh
   93 root      2092 R    ps
~ #

My original problem is that the ethernet performance is very low with
small windows. I thought that I can control this value by changing
sleep_latency parameter in
the following array. Yet, it did not help me. I don't know why.


static struct cpuidle_params cpuidle_params_table[] = {
/* C1 */
    {0, 2, 2, 5},        <-- changed valid to 0 (I am interested in
getting into deepest state)
/* C2 */
    {0, 10, 10, 30},     <-- changed valid to 0 (I am interested in
getting into deepest state)
/* C3 */
    {0, 50 , 50, 300},     <-- changed valid to 0 (I am interested in
getting into deepest state)
    /* C4 */
    {1, 1500000 , 1800, 4000},     <-- changed sleep_latency to 1500000
....
}


Best Regards,
Ran

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: power states transitions
  2015-11-22 15:58 power states transitions Ran Shalit
@ 2015-11-25 18:50 ` Tony Lindgren
  2015-11-25 19:48   ` Ran Shalit
  0 siblings, 1 reply; 4+ messages in thread
From: Tony Lindgren @ 2015-11-25 18:50 UTC (permalink / raw)
  To: Ran Shalit; +Cc: Linux OMAP Mailing List, linux-pm

* Ran Shalit <ranshalit@gmail.com> [151122 07:59]:
> Hello,
> 
> I have stranhe behaviour in which even when there is no activity in
> serial port, the retention counter is keep incremented all these time,
> as if the cpu gets in and out of retention periodically.
> I would expect the cpu to get into retention mode, when there is no
> activity and stay in that state.
> What can cause such behaviour ? Is it because some background process ?

Sounds like your device is hitting deper idle states during idle. If
you want to disable that, set the UART autosuspend_delay_ms to -1:

#/bin/bash
uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
        echo -1 > $uart/autosuspend_delay_ms 2>&1
done

The above will keep the UARTs active blocking any deeper idle
states. I believe the value has to be -1 instead of 0 to disable
autoidle.. but please verify yourself.

> My original problem is that the ethernet performance is very low with
> small windows. I thought that I can control this value by changing
> sleep_latency parameter in
> the following array. Yet, it did not help me. I don't know why.

Maybe test if the above script helps with the Ethernet too. If the
Ethernet controller is on GPMC, it's not blocking deeper idle states
automatically in hardware. Adding DMA support to the Ethernet driver
would be a good way to block deeper idle states automatically by
the Ethernet hardware.

Regards,

Tony

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: power states transitions
  2015-11-25 18:50 ` Tony Lindgren
@ 2015-11-25 19:48   ` Ran Shalit
  2015-11-25 21:11     ` Tony Lindgren
  0 siblings, 1 reply; 4+ messages in thread
From: Ran Shalit @ 2015-11-25 19:48 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: Linux OMAP Mailing List, linux-pm

On Wed, Nov 25, 2015 at 8:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ran Shalit <ranshalit@gmail.com> [151122 07:59]:
>> Hello,
>>
>> I have stranhe behaviour in which even when there is no activity in
>> serial port, the retention counter is keep incremented all these time,
>> as if the cpu gets in and out of retention periodically.
>> I would expect the cpu to get into retention mode, when there is no
>> activity and stay in that state.
>> What can cause such behaviour ? Is it because some background process ?
>
> Sounds like your device is hitting deper idle states during idle. If
> you want to disable that, set the UART autosuspend_delay_ms to -1:
>
> #/bin/bash
> uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
> for uart in $uarts; do
>         echo -1 > $uart/autosuspend_delay_ms 2>&1
> done
>
> The above will keep the UARTs active blocking any deeper idle
> states. I believe the value has to be -1 instead of 0 to disable
> autoidle.. but please verify yourself.
>
>> My original problem is that the ethernet performance is very low with
>> small windows. I thought that I can control this value by changing
>> sleep_latency parameter in
>> the following array. Yet, it did not help me. I don't know why.
>
> Maybe test if the above script helps with the Ethernet too. If the
> Ethernet controller is on GPMC, it's not blocking deeper idle states
> automatically in hardware. Adding DMA support to the Ethernet driver
> would be a good way to block deeper idle states automatically by
> the Ethernet hardware.
>

Hi Tony,

We actually want the deeper state, but not in the price of performance...
So I thought of these possibilities:
1. configure the sleep state to check activity for a longer time than
micro seconds (several seconds). If there is non activity in that long
period, only than will move to retention. I am not sure if there is
such configuration parameter . Maybe one of the following parameters
can be configured for this option ?

46 struct cpuidle_params {
 47         u32 exit_latency;       /* exit_latency = sleep + wake-up
latencies */
 48         u32 target_residency;
 49         u8 valid;               /* validates the C-state */
 50 };

2. Another option can be to write a kernel module which check if there
is ethernet activity for X seconds, if there is none - it will enable
power management , otherwise - it will disable the power management.

These maybe can solve the ethernet issue, but I still not sure why
there is constantly incrementation in the retention state, as if it
enter and leave the state all periodically. Is it becuase some
task/thread/process in the system (I guess it can be a kernel process
actually) ?

Regards,
Ran

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: power states transitions
  2015-11-25 19:48   ` Ran Shalit
@ 2015-11-25 21:11     ` Tony Lindgren
  0 siblings, 0 replies; 4+ messages in thread
From: Tony Lindgren @ 2015-11-25 21:11 UTC (permalink / raw)
  To: Ran Shalit; +Cc: Linux OMAP Mailing List, linux-pm

* Ran Shalit <ranshalit@gmail.com> [151125 11:49]:
> On Wed, Nov 25, 2015 at 8:50 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> We actually want the deeper state, but not in the price of performance...
> So I thought of these possibilities:
> 1. configure the sleep state to check activity for a longer time than
> micro seconds (several seconds). If there is non activity in that long
> period, only than will move to retention. I am not sure if there is
> such configuration parameter . Maybe one of the following parameters
> can be configured for this option ?
> 
> 46 struct cpuidle_params {
>  47         u32 exit_latency;       /* exit_latency = sleep + wake-up
> latencies */
>  48         u32 target_residency;
>  49         u8 valid;               /* validates the C-state */
>  50 };
> 
> 2. Another option can be to write a kernel module which check if there
> is ethernet activity for X seconds, if there is none - it will enable
> power management , otherwise - it will disable the power management.

It really should be implemented with the standard pm_runtime calls in the
Ethernet driver. Maybe you can clk_get some parent clock from the Ethernet
driver that will block the idle state?

> These maybe can solve the ethernet issue, but I still not sure why
> there is constantly incrementation in the retention state, as if it
> enter and leave the state all periodically. Is it becuase some
> task/thread/process in the system (I guess it can be a kernel process
> actually) ?

I think what you're seeing is the kernel idle code incrementing it
every time the SoC hits idle.

Regards,

Tony

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-11-25 21:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-22 15:58 power states transitions Ran Shalit
2015-11-25 18:50 ` Tony Lindgren
2015-11-25 19:48   ` Ran Shalit
2015-11-25 21:11     ` Tony Lindgren

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).