Dear Dev,
Your parcel has arrived at May 28. Courier was unable to deliver the parcel to you.
Shipment Label is attached to email.
Yours trully,
Warren Carney,
Sr. Support Manager.
Dear Dev,
We could not deliver your item.
You can review complete details of your order in the find attached.
Yours faithfully,
Dwight Mccall,
Sr. Delivery Manager.
Hi Deitmar,
[ + eas-dev ]
On Sun, May 22, 2016 at 06:06:47PM +0100, Dietmar Eggemann wrote:
> On 05/21/2016 06:25 AM, Leo Yan wrote:
> >On Fri, May 20, 2016 at 08:08:16PM +0100, Dietmar Eggemann wrote:
> >>Hi Leo,
> >>
> >>try the attached testcase in LISA which runs the wl's in '/tg_1/tg_11'
> >>You can create different tg level-hierarchies in rfc_tg.config if you wish.
> >>
> >>08:05:17 DEBUG : sudo -- sh -c '/root/devlib-target/bin/shutils cgroups_run_into /tg_1/tg_11 '\''/root/devlib-target/bin/rt-app /root/devlib-target/run_dir/06_pct_00.json'\'''
> >
> >Very appreciate for the case.
>
> I thought about this again and maybe you want to test task migration of
> a task running in a task group? This would make much more sense than
> only running task in a task group in case you want to test the pelt signals.
After enable EAS, I can see the task running in task group is migrated
between different CPUs when task is waken up.
> I added some functionality to rt-app which lets you restrict the cpu
> affinity of a task per phase of its run so you can create a task inside
> a task group which alternates between two cpus while running. This
> migration is done by the running task (so it's
> sched_setaffinity()->__set_cpus_allowed_ptr()->stop_one_cpu(...,
> migration_cpu_stop, ...)->__migrate_task()->move_queued_task()
>
> So if you interested in this just ask me on eas-dev so I can share the
> rt-app functionality and a how-to build rt-app on the list for a broader
> audience.
Yes, this is another path we should test for task migration. So could
you share this on mailing list? We also can consider to integrate this
into rt-app's repo.
Thanks,
Leo Yan
In current code the CPU's idle state cpufreq_pstates::idle is initialized
to '-1'; and until parse first "cpu_idle" event for the CPU then set CPU's
idle state to '0' or '1' corresponding to active or idle. This will cause
error for P-state's statistics: from the beginning to first "cpu_idle"
event, during this period the CPU's idle state is '-1' so function
cpu_change_pstate() will always think it's first update and finally abandon
previous time.
This will introduce very big error if the CPU is always running and never
run into idle state. So this patch is to fix this issue by initialize CPU's
idle state before parse P-state and C-state's time. Initialize CPU's idle
state according to first cpu_idle log:
- If the CPU first cpu_idle state is '-1', that means from the beginning
the CPU is stayed on idle state;
- If the CPU first cpu_idle state is other value, means the CPU is active.
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
---
tracefile_idlestat.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/tracefile_idlestat.c b/tracefile_idlestat.c
index 3430693..fb0b3d8 100644
--- a/tracefile_idlestat.c
+++ b/tracefile_idlestat.c
@@ -152,6 +152,55 @@ int load_text_data_line(char *buffer, struct cpuidle_datas *datas, char *format,
return get_wakeup_irq(datas, buffer);
}
+/**
+ * init_cpu_idle_state - Init CPU's idle state according to first cpu_idle log.
+ * For a specific cpu_idle event, its state is '-1' then that means from the
+ * beginning the CPU is stayed on idle state; Otherwise means the CPU is active.
+ * So initilize per-CPU idle flag to get more accurate time.
+ *
+ * @datas: structure for P-state and C-state's statistics
+ * @f: the file handle of the idlestat trace file
+ */
+void init_cpu_idle_state(struct cpuidle_datas *datas, FILE *f)
+{
+ struct cpufreq_pstates *ps;
+ unsigned int state, freq, cpu;
+ double time;
+ char buffer[BUFSIZE];
+
+ do {
+ if (strstr(buffer, "cpu_idle")) {
+ if (sscanf(buffer, TRACE_FORMAT, &time, &state, &cpu)
+ != 3) {
+ fprintf(stderr, "warning: Unrecognized cpuidle "
+ "record. The result of analysis might "
+ "be wrong.\n");
+ return -1;
+ }
+ }
+
+ ps = &(datas->pstates[cpu]);
+
+ /* CPU's state has been initialized, skip it */
+ if (ps->idle != -1)
+ continue;
+
+ /*
+ * The CPU's first cpu_idle is '-1', means CPU is staying in
+ * idle state and exit from idle until first cpu_idle event.
+ * Otherwise, means the CPU is active at beginning.
+ */
+ if (state == -1)
+ ps->idle = 1;
+ else
+ ps->idle = 0;
+
+ } while (fgets(buffer, BUFSIZE, f));
+
+ /* After traverse file, reset offset */
+ fseek(f, 0, SEEK_SET);
+}
+
void load_text_data_lines(FILE *f, char *buffer, struct cpuidle_datas *datas)
{
double begin = 0, end = 0;
@@ -159,6 +208,8 @@ void load_text_data_lines(FILE *f, char *buffer, struct cpuidle_datas *datas)
setup_topo_states(datas);
+ init_cpu_idle_state(datas, f);
+
do {
if (load_text_data_line(buffer, datas, TRACE_FORMAT,
&begin, &end, &start) != -1) {
--
1.9.1
Hi Patrick,
[ + eas-dev ]
With non-root user in Android, I cannot add PID to SchedTune's cgroup;
At beginning I thought it's related with cgroup's file node
attribution, so tried to use "root" user to change permission with
"a+rwx", even so still cannot set cgroup's node by non-root user.
hikey:/ $ su
hikey:/ # chmod a+rwx /sys/fs/cgroup/stune/performance/cgroup.procs
hikey:/ # exit
hikey:/ $ echo 1937 > /sys/fs/cgroup/stune/performance/cgroup.procs
hikey:/ $ cat /sys/fs/cgroup/stune/performance/cgroup.procs
Do you have suggestion for what's the formal method for adding PID to
SchedTune's cgroup with non-root user?
Thanks,
Leo Yan