#12538 NORM 4-softw: XO-4 CPU usage at idle is high

[Zarro Boogs per Child]

#12538: XO-4 CPU usage at idle is high
------------------------------------+---------------------------------------
           Reporter:  dsd           |       Owner:  cjb          
               Type:  defect        |      Status:  new          
           Priority:  normal        |   Milestone:  4-software   
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  add to build  |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------
Changes (by dsd):

  * next_action:  never set => add to build


Comment:

 Replying to [comment:2 cjb]:
 > in sdhci.c:
 > {{{
 >    mmc_detect_change(host->mmc, msecs_to_jiffies(200));
 > }}}
 >
 > Would be good to see how the load changes after s/200/2000/.

 I think this 200ms delay is a debounce delay, only executed in response to
 a card detected/removed interrupt (which we never receive).

 The polling frequency is instead defined in mmc_rescan itself:
 {{{
                 mmc_schedule_delayed_work(&host->detect, HZ);
 }}}

 Once per second does not seem excessive. I tried increasing and decreasing
 this value, didn't observe any real change in idle %.

 Another new observation... In my earlier experiment, I had removed these
 lines only, thinking I was matching what had been described on IRC as
 making the idle % go back to near-100:
 {{{
 pr_info("%s: FIXME: setting broken card detection quirk
 host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
 }}}

 However, with those lines removed, polling does indeed stop on mmc2
 (external SD) but continues on mmc3 (internal SD) because it has the
 equivalent flag (broken-cd) set in the device tree.

 As improving this polling situation isn't hard, I decided to do it anyway.
 Internal SD can be regarded as non-removable, so the polling will stop
 there (#12561). And I pushed a92e022..ae57531 to arm-3.5 to enable usage
 of the card detection GPIO on the external SD slot, disabling polling
 there too.

 Now there really is no more polling going on, and top does show
 significantly better idle % numbers (90-95%). I suspect the polling was
 never using as much as it was previously suggesting, rather we were being
 hit by a nohz bug causing bad reporting of the numbers, but anyway.

 With this in place, when the system really is idle the percentages seem
 high enough, which should mean that powerd goes back to suspending on a
 regular basis (even with nohz on). I think we can leave it at that for
 now.

-- 
Ticket URL: <http://dev.laptop.org/ticket/12538#comment:6>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system