All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Zhbanov <i.zhbanov at samsung.com>
To: powertop@lists.01.org
Subject: [Powertop] Powertop doesn't detects sleeping ARM cores
Date: Mon, 17 Sep 2012 16:57:51 +0400	[thread overview]
Message-ID: <50571E4F.1010604@samsung.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]

Hello!

When you start the PowerTOP on a "cold" ARM phone with several cores and low CPU average
some cores could be powered down. It is very frequent situation on ARM platform to dynamically
turn cores on/off to save power.

And when the PowerTOP scans /proc/cpuinfo file in enumerate_cpus() function, it will see
only one working core, so PowerTOP calls handle_one_cpu(...) only once and sets number of CPUs to 1.
So the PowerTOP will not register trace events for other cores.

Later when the system load (during the lifetime of PowerTOP) increases, the Linux kernel powers-up
additional cores. But the PowerTOP will not catch events for them.

I thought about scanning the /sys/devices/system/cpu/ directory for finding out how many CPUs
the system has. But the problem is that the directories for CPUs in offline mode doesn't provide
needed subdirectories cpuidle/ and topology/ (also it misses some files in cpufreq/ directory).

The only way to enable these directories is to (temporarily?) turn the core on.
This could be done e.g. by writing 1 to cpu/cpuX/online.
But I'm not sure how long the core will stay online before the kernel turns it off again because of
low load. On my phone this happens in a less than a second.

Another possible way is to scan /sys/.../cpu/ for the number of CPUs in the system,
register trace events for all that CPUs (by the way, is it possible to register a trace event
for the core that is now off?), sleep for the needed amount of time as usual, and before
the processing of data, temporarily turn every core on to find out information about it.

Or the PowerTOP could remember which cores was turned on before the testing, turn it all on,
read needed info, turn some cores off to restore the state of the system and begin test.

Or it could scan /sys/.../cpu/ with some interval (1 second) instead of just sleeping,
and grab the information about new cores brought online.

By the way, the PowerTOP scans /proc/ directory twice -- once before the start and once after
to get information about processes (to provide more information from trace events).
But if some process starts after the PowerTOP begins to sleep, and dies before the sleep ends,
then the PowerTOP will be unable to get information about that process (e.g. command line).
So the PowerTOP will know only its PID and shortened version of the command line (task->comm[16]).

I have a patch adding scanning of /proc/ capabilities to the PowerTOP. I use this /proc/ scanner
in MALI supporting patch, because MALI provides only the PID of the process in their events,
and that is not enough to know about the process. It needs more discussion so I will send the patch
little later. But I want to notice, that it could be useful for the rest of the PowerTOP too
to catch that processes. (The best solution will be to catch the process exit, but that event
provides only short task->comm[16]).

Anyway, the PowerTOP could do more instead of just sleeping.

What do you think?

Thank you.

-- 
Best regards,
Igor Zhbanov,
Expert Software Engineer,
phone: +7 (495) 797 25 00 ext 3806
e-mail: i.zhbanov(a)samsung.com

ASWG, Moscow R&D center, Samsung Electronics
12 Dvintsev street, building 1
127018, Moscow, Russian Federation


             reply	other threads:[~2012-09-17 12:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-17 12:57 Igor Zhbanov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-09-19  8:26 [Powertop] Powertop doesn't detects sleeping ARM cores Igor Zhbanov
2012-09-19 15:15 Chris Ferron
2012-09-20  8:24 Igor Zhbanov
2012-09-20  9:14 Sergey Senozhatsky
2012-09-20  9:29 Igor Zhbanov
2012-09-20  9:43 Sergey Senozhatsky
2012-09-20  9:56 Arjan van de Ven
2012-09-20  9:57 Igor Zhbanov
2012-09-20 10:40 Igor Zhbanov
2012-09-20 10:42 Arjan van de Ven
2012-09-20 10:55 Igor Zhbanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50571E4F.1010604@samsung.com \
    --to=powertop@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.