Re: [PATCH 2/6] sched: add a new SD SHARE_POWERLINE flag for sched_domain
On 13 December 2012 03:24, Alex Shi wrote:
> On 12/12/2012 09:31 PM, Vincent Guittot wrote:
>> This new flag SD_SHARE_POWERDOMAIN is used to reflect whether groups of CPU
>> in
>> a sched_domain level can or not reach a different power state. If clusters
>> can
>> be power gated independently, as an example, the flag should be cleared at
>> CPU
>> level. This information is used to decide if it's worth packing some tasks in
>> a group of CPUs in order to power gated the other groups instead of spreading
>> the tasks. The default behavior of the scheduler is to spread tasks so the
>> flag is set into all sched_domains
>>
>> Signed-off-by: Vincent Guittot
>> ---
>> arch/ia64/include/asm/topology.h |1 +
>> arch/tile/include/asm/topology.h |1 +
>> include/linux/sched.h|1 +
>> include/linux/topology.h |4
>> kernel/sched/core.c |6 ++
>> 5 files changed, 13 insertions(+)
>>
>> diff --git a/arch/ia64/include/asm/topology.h
>> b/arch/ia64/include/asm/topology.h
>> index a2496e4..6d0b617 100644
>> --- a/arch/ia64/include/asm/topology.h
>> +++ b/arch/ia64/include/asm/topology.h
>> @@ -65,6 +65,7 @@ void build_cpu_to_node_map(void);
>> | SD_BALANCE_EXEC \
>> | SD_BALANCE_FORK \
>> | SD_WAKE_AFFINE, \
>> + | arch_sd_local_flags(0)\
>> .last_balance = jiffies, \
>> .balance_interval = 1,\
>> .nr_balance_failed = 0,\
>> diff --git a/arch/tile/include/asm/topology.h
>> b/arch/tile/include/asm/topology.h
>> index d5e86c9..adc8710 100644
>> --- a/arch/tile/include/asm/topology.h
>> +++ b/arch/tile/include/asm/topology.h
>> @@ -71,6 +71,7 @@ static inline const struct cpumask *cpumask_of_node(int
>> node)
>> | 0*SD_WAKE_AFFINE \
>> | 0*SD_SHARE_CPUPOWER \
>> | 0*SD_SHARE_PKG_RESOURCES \
>> + | arch_sd_local_flags(0)\
>> | 0*SD_SERIALIZE\
>> , \
>> .last_balance = jiffies, \
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index 046e39a..3287be1 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -844,6 +844,7 @@ enum cpu_idle_type {
>> #define SD_BALANCE_WAKE 0x0010 /* Balance on wakeup */
>> #define SD_WAKE_AFFINE 0x0020 /* Wake task to waking CPU */
>> #define SD_SHARE_CPUPOWER0x0080 /* Domain members share cpu power */
>> +#define SD_SHARE_POWERDOMAIN 0x0100 /* Domain members share power domain */
>> #define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu
>> pkg resources */
>> #define SD_SERIALIZE 0x0400 /* Only a single load balancing
>> instance */
>> #define SD_ASYM_PACKING 0x0800 /* Place busy groups earlier
>> in the domain */
>> diff --git a/include/linux/topology.h b/include/linux/topology.h
>> index d3cf0d6..3eab293 100644
>> --- a/include/linux/topology.h
>> +++ b/include/linux/topology.h
>> @@ -99,6 +99,8 @@ int arch_update_cpu_topology(void);
>> | 1*SD_WAKE_AFFINE \
>> | 1*SD_SHARE_CPUPOWER \
>> | 1*SD_SHARE_PKG_RESOURCES \
>> + | arch_sd_local_flags(SD_SHARE_CPUPOWER|\
>> + SD_SHARE_PKG_RESOURCES) \
>> | 0*SD_SERIALIZE\
>> | 0*SD_PREFER_SIBLING \
>> | arch_sd_sibling_asym_packing()\
>> @@ -131,6 +133,7 @@ int arch_update_cpu_topology(void);
>> | 1*SD_WAKE_AFFINE \
>> | 0*SD_SHARE_CPUPOWER \
>> | 1*SD_SHARE_PKG_RESOURCES \
>> + | arch_sd_local_flags(SD_SHARE_PKG_RESOURCES)\
>> | 0*SD_SERIALIZE\
>> , \
>> .last_balance = jiffies, \
>> @@ -161,6 +164,7 @@ int arch_update_cpu_topology(void);
>> | 1*SD_WAKE_AFFINE \
>> | 0*SD_SHARE_CPUPOWER \
>> | 0*SD_SHARE_PKG_RESOURCES \
>> + | arch_sd_local_flags(0)
l.a.m.c failed on Validation linaro server.
Hi, I have tried to build linaro.img on validation.linaro.org and found below error. I request you provide way forward on this. $ linaro-android-media-create --image-file linaro.img --image-size 2000M --dev vexpress --boot boot.tar.bz2 --system system.tar.bz2 --userdata userdata.tar.bz2 Traceback (most recent call last): File "/usr/bin/linaro-android-media-create", line 105, in board_config = android_board_configs[args.dev] AttributeError: 'Namespace' object has no attribute 'dev' [sudo] password for naresh-kamboju: $ ls boot.tar.bz2 system.tar.bz2 userdata.tar.bz2 Best regards Naresh Kamboju ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: l.a.m.c failed on Validation linaro server.
Hi, I have fixed this error by download ( https://launchpad.net/linaro-image-tools ) image on to my home folder on validation server and executed from absolute path and it is working. Best regards Naresh Kamboju On 13 December 2012 14:31, Naresh Kamboju wrote: > Hi, > > I have tried to build linaro.img on validation.linaro.org and found below > error. I request you provide way forward on this. > > $ linaro-android-media-create --image-file linaro.img --image-size 2000M > --dev vexpress --boot boot.tar.bz2 --system system.tar.bz2 --userdata > userdata.tar.bz2 > Traceback (most recent call last): > File "/usr/bin/linaro-android-media-create", line 105, in > board_config = android_board_configs[args.dev] > AttributeError: 'Namespace' object has no attribute 'dev' > [sudo] password for naresh-kamboju: > $ ls > boot.tar.bz2 system.tar.bz2 userdata.tar.bz2 > > > Best regards > Naresh Kamboju > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Fwd: Minor downtime
Adding other interested parties. Dave Begin forwarded message: > From: Dave Pigott > Subject: Minor downtime > Date: 13 December 2012 09:37:30 GMT > To: "linaro-validat...@lists.linaro.org Validation" > > > Hi all, > > As part of my investigations into our IP addressing issue, I am going to > reboot one of the Cisco switches in the lab. This will mean downtime of maybe > a few minutes, and will happen later today. It means that Pandas 05-24, > Origens 02-10 and the Toolchain pandas will be unavailable during that time. > > Thanks > > Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Patch for YAML test definitions
Hi, I converted lava-test test definitions to work on lava-test-shell with the new YAML format. These converted tests are mostly from https://code.launchpad.net/~linaro-foundations I request someone from developer platform team to merge these tests to the bzr repositories so that it will be easy to maintain these tests in future. PFA the patches and the following are the repositories to which the patch should be applied: 1) lp:~linaro-foundations/linaro-ubuntu/lava-test-device-tree - device-tree-patch.txt 2) lp:~linaro-foundations/linaro-ubuntu/lava-test-bt-enablement - bt-enablement-patch.txt 3) lp:~linaro-foundations/linaro-ubuntu/lava-test-basic-graphics - basic-graphics-patch.txt 4) lp:~linaro-foundations/linaro-ubuntu/lava-test-wifi-enablement - wifi-enablement-patch.txt 5) lp:~linaro-foundations/lava-test/lava-perf-test - perf-test-patch.txt 6) lp:~linaro-foundations/lava-test/new-test-definitions - other-tests-patch.txt Thank You. -- Senthil Kumaran S http://www.stylesen.org/ http://www.sasenthilkumaran.com/ === added directory 'yaml' === added file 'yaml/basic-graphics.yaml' --- yaml/basic-graphics.yaml1970-01-01 00:00:00 + +++ yaml/basic-graphics.yaml2012-12-13 09:29:26 + @@ -0,0 +1,21 @@ +metadata: +name: leb-basic-graphics +version: 1.0 +format: "Lava-Test-Shell Test Definition 1.0" + +install: +bzr-repos: +- lp:~linaro-foundations/linaro-ubuntu/lava-test-basic-graphics +deps: +- mesa-utils-extra +- ubuntu-desktop + +run: +steps: +- "cd lava-test-basic-graphics; sudo bash -x ./run-test.sh" + +parse: +pattern: "(?P[a-zA-Z0-9_-]+):\\s(?P\\w+)" +fixupdict: +PASS: pass +FAIL: fail === added directory 'yaml' === added file 'yaml/bt-enablement.yaml' --- yaml/bt-enablement.yaml 1970-01-01 00:00:00 + +++ yaml/bt-enablement.yaml 2012-12-13 09:27:03 + @@ -0,0 +1,20 @@ +metadata: +name: bluetooth-enablement +version: 1.0 +format: "Lava-Test-Shell Test Definition 1.0" + +install: +bzr-repos: +- lp:~linaro-foundations/linaro-ubuntu/lava-test-bt-enablement +deps: +- bluez + +run: +steps: +- "cd lava-test-bt-enablement; sudo bash -x ./run-test.sh" + +parse: +pattern: "(?P[a-zA-Z0-9_-]+):\\s(?P\\w+)" +fixupdict: +PASS: pass +FAIL: fail === added directory 'yaml' === added file 'yaml/device-tree.yaml' --- yaml/device-tree.yaml 1970-01-01 00:00:00 + +++ yaml/device-tree.yaml 2012-12-13 08:59:14 + @@ -0,0 +1,18 @@ +metadata: +name: device-tree-test +version: 1.0 +format: "Lava-Test-Shell Test Definition 1.0" + +install: +bzr-repos: +- lp:~linaro-foundations/linaro-ubuntu/lava-test-device-tree + +run: +steps: +- "cd lava-test-device-tree; sudo bash -x ./run-test.sh" + +parse: +pattern: "(?P[a-zA-Z0-9_-]+):\\s(?P\\w+)" +fixupdict: +PASS: pass +FAIL: fail === added directory 'yaml' === added file 'yaml/e2eaudiotest.yaml' --- yaml/e2eaudiotest.yaml 1970-01-01 00:00:00 + +++ yaml/e2eaudiotest.yaml 2012-12-13 09:38:22 + @@ -0,0 +1,19 @@ +metadata: +name: e2eaudiotest +version: 1.0 +format: "Lava-Test-Shell Test Definition 1.0" + +install: +deps: +- libasound2-dev +- libfftw3-dev +- gcc +git-repos: +- git://git.linaro.org/people/kurt-r-taylor/e2eaudiotest.git +steps: +- "cd e2eaudiotest; gcc testfreq.c utils_alsa.c -lasound -lfftw3 -o testfreq" + +run: +steps: +- cd e2eaudiotest +- "lava-test-case ./e2eaudiotest.sh --result pass --measurement 100 --units Hz" === added file 'yaml/gatortests.yaml' --- yaml/gatortests.yaml1970-01-01 00:00:00 + +++ yaml/gatortests.yaml2012-12-13 09:38:19 + @@ -0,0 +1,12 @@ +metadata: +name: gatortests +version: 1.0 +format: "Lava-Test-Shell Test Definition 1.0" + +install: +deps: +- gatortests + +run: +steps: +- "lava-test-case gatortests --result pass" === added file 'yaml/pwrmgmt.yaml' --- yaml/pwrmgmt.yaml 1970-01-01 00:00:00 + +++ yaml/pwrmgmt.yaml 2012-12-13 09:38:14 + @@ -0,0 +1,24 @@ +metadata: +name: pwrmgmt +version: 1.0 +format: "Lava-Test-Shell Test Definition 1.0" + +install: +deps: +- linux-libc-dev +- build-essential +git-repos: +- git://git.linaro.org/tools/pm-qa.git +steps: +- "cd pm-qa && make -C utils" + +run: +steps: +- cd pm-qa +- make -k check + +parse: +pattern: "^(?P[\\w/\\.]+):\\s+(?P.+)\\.\\.\\.\\s+(?P\\w+)" +fixupdict: +PASS: pass +FAIL: fail === added directory 'yaml' === added file 'yaml/perf-test.yaml' --- yaml/perf-test.yaml 1970-01-01 00:00:00 + +++ yaml/perf-test.yaml 2012-12-13 09:33:55 + @@ -0,0 +1,21 @@ +metadata: +name: linaro.perf +version: 1.0 +format: "Lava-Test-Shell
Re: [RFC PATCH v2 3/6] sched: pack small tasks
On 13 December 2012 03:17, Alex Shi wrote:
> On 12/12/2012 09:31 PM, Vincent Guittot wrote:
>> During the creation of sched_domain, we define a pack buddy CPU for each CPU
>> when one is available. We want to pack at all levels where a group of CPU can
>> be power gated independently from others.
>> On a system that can't power gate a group of CPUs independently, the flag is
>> set at all sched_domain level and the buddy is set to -1. This is the default
>> behavior.
>> On a dual clusters / dual cores system which can power gate each core and
>> cluster independently, the buddy configuration will be :
>>
>> | Cluster 0 | Cluster 1 |
>> | CPU0 | CPU1 | CPU2 | CPU3 |
>> ---
>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>>
>> Small tasks tend to slip out of the periodic load balance so the best place
>> to choose to migrate them is during their wake up. The decision is in O(1) as
>> we only check again one buddy CPU
>
> Just have a little worry about the scalability on a big machine, like on
> a 4 sockets NUMA machine * 8 cores * HT machine, the buddy cpu in whole
> system need care 64 LCPUs. and in your case cpu0 just care 4 LCPU. That
> is different on task distribution decision.
The buddy CPU should probably not be the same for all 64 LCPU it
depends on where it's worth packing small tasks
Which kind of sched_domain configuration have you for such system ?
and how many sched_domain level have you ?
>
>>
>> Signed-off-by: Vincent Guittot
>> ---
>> kernel/sched/core.c |1 +
>> kernel/sched/fair.c | 110
>> ++
>> kernel/sched/sched.h |5 +++
>> 3 files changed, 116 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 4f36e9d..3436aad 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -5693,6 +5693,7 @@ cpu_attach_domain(struct sched_domain *sd, struct
>> root_domain *rd, int cpu)
>> rcu_assign_pointer(rq->sd, sd);
>> destroy_sched_domains(tmp, cpu);
>>
>> + update_packing_domain(cpu);
>> update_domain_cache(cpu);
>> }
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 9916d41..fc93d96 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -163,6 +163,73 @@ void sched_init_granularity(void)
>> update_sysctl();
>> }
>>
>> +
>> +#ifdef CONFIG_SMP
>> +/*
>> + * Save the id of the optimal CPU that should be used to pack small tasks
>> + * The value -1 is used when no buddy has been found
>> + */
>> +DEFINE_PER_CPU(int, sd_pack_buddy);
>> +
>> +/* Look for the best buddy CPU that can be used to pack small tasks
>> + * We make the assumption that it doesn't wort to pack on CPU that share the
>> + * same powerline. We looks for the 1st sched_domain without the
>> + * SD_SHARE_POWERDOMAIN flag. Then We look for the sched_group witht the
>> lowest
>> + * power per core based on the assumption that their power efficiency is
>> + * better */
>> +void update_packing_domain(int cpu)
>> +{
>> + struct sched_domain *sd;
>> + int id = -1;
>> +
>> + sd = highest_flag_domain(cpu, SD_SHARE_POWERDOMAIN & SD_LOAD_BALANCE);
>> + if (!sd)
>> + sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
>> + else
>> + sd = sd->parent;
>> +
>> + while (sd && (sd->flags && SD_LOAD_BALANCE)) {
>> + struct sched_group *sg = sd->groups;
>> + struct sched_group *pack = sg;
>> + struct sched_group *tmp;
>> +
>> + /*
>> + * The sched_domain of a CPU points on the local sched_group
>> + * and the 1st CPU of this local group is a good candidate
>> + */
>> + id = cpumask_first(sched_group_cpus(pack));
>> +
>> + /* loop the sched groups to find the best one */
>> + for (tmp = sg->next; tmp != sg; tmp = tmp->next) {
>> + if (tmp->sgp->power * pack->group_weight >
>> + pack->sgp->power * tmp->group_weight)
>> + continue;
>> +
>> + if ((tmp->sgp->power * pack->group_weight ==
>> + pack->sgp->power * tmp->group_weight)
>> + && (cpumask_first(sched_group_cpus(tmp)) >= id))
>> + continue;
>> +
>> + /* we have found a better group */
>> + pack = tmp;
>> +
>> + /* Take the 1st CPU of the new group */
>> + id = cpumask_first(sched_group_cpus(pack));
>> + }
>> +
>> + /* Look for another CPU than itself */
>> + if (id != cpu)
>> + break;
>> +
>> + sd = sd->parent;
>> + }
>> +
>> + pr_debug("CPU%d packing on CPU%d\n", cpu, id);
>> + per_cpu(sd_pack_buddy, cpu) = id;
>> +}
>> +
>> +#endif /* CONFIG_SMP */
>> +
>> #if BITS_PER_LO
Re: [Linaro-validation] Patch for YAML test definitions
Hi, On 13 December 2012 11:48, Senthil Kumaran wrote: > Hi, > > I converted lava-test test definitions to work on lava-test-shell with the > new YAML format. These converted tests are mostly from > https://code.launchpad.net/~linaro-foundations > > I request someone from developer platform team to merge these tests to the > bzr repositories so that it will be easy to maintain these tests in future. Commited. Thanks Senthil. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] linux-linaro kernel schedule for 12.12
On 12/13/2012 02:14 AM, Andrey Konovalov wrote: > Greetings, > > The ll tree has been updated to use llct-20121211.0 as the base. > It still has just the ARM LT topic; waiting for the v3.7 based topic > from Samsung LT. v3.7 based Samsung LT kernel has been pushed to glo. [1] [1] http://git.linaro.org/gitweb?p=landing-teams/working/samsung/kernel.git;a=shortlog;h=refs/heads/tracking Issues: * Ethernet still broken on Ubuntu. (Same status as 3.7-rc6, interesting Android kernel built from the same source has working ethernet connection.) * Android kernel doesn't compile because of some change in gpu/ion. Even after adding fixes for compilation errors there is crash during booting, so didn't push those fixes. I hope we will have some more time for any critical fixes. > Also the hack by Bero to make perf to build on android has been removed: > will see if it break the perf build on ubuntu (see the > LinuxLinaroKernelSchedule for more details). > > * December 13 is the last date to update ll for 12.12 * > > The current status and the schedule is: > https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule > > Thanks, > Andrey > > On 12/11/2012 01:54 PM, Andrey Konovalov wrote: >> The llct based on v3.7 release is there, and is tagged llct-20121211.0 > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Minor downtime
Hi all, OK. I reconfigured dnsmasq so that the switches all get a fixed address, and documented this. I then reset switch02 (the offending one) and went round every board, including toolchain, and everything got its address perfectly. All boards now back online and running health checks in LAVA. While I was on each board I've also taken their MAC address and documented that (sorry - it's not a completely open document because it contains security information) and as Michael H noted there are indeed one or two pandas with the same MAC address, which means that I can't serve IP addresses from dnsmasq to the toolchain boards, so they're still hardwired. Thanks for your patience Dave On 13 Dec 2012, at 09:43, Dave Pigott wrote: > Adding other interested parties. > > Dave > > Begin forwarded message: > >> From: Dave Pigott >> Subject: Minor downtime >> Date: 13 December 2012 09:37:30 GMT >> To: "linaro-validat...@lists.linaro.org Validation" >> >> >> Hi all, >> >> As part of my investigations into our IP addressing issue, I am going to >> reboot one of the Cisco switches in the lab. This will mean downtime of >> maybe a few minutes, and will happen later today. It means that Pandas >> 05-24, Origens 02-10 and the Toolchain pandas will be unavailable during >> that time. >> >> Thanks >> >> Dave > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v2 3/6] sched: pack small tasks
On 12/13/2012 06:11 PM, Vincent Guittot wrote: > On 13 December 2012 03:17, Alex Shi wrote: >> On 12/12/2012 09:31 PM, Vincent Guittot wrote: >>> During the creation of sched_domain, we define a pack buddy CPU for each CPU >>> when one is available. We want to pack at all levels where a group of CPU >>> can >>> be power gated independently from others. >>> On a system that can't power gate a group of CPUs independently, the flag is >>> set at all sched_domain level and the buddy is set to -1. This is the >>> default >>> behavior. >>> On a dual clusters / dual cores system which can power gate each core and >>> cluster independently, the buddy configuration will be : >>> >>> | Cluster 0 | Cluster 1 | >>> | CPU0 | CPU1 | CPU2 | CPU3 | >>> --- >>> buddy | CPU0 | CPU0 | CPU0 | CPU2 | >>> >>> Small tasks tend to slip out of the periodic load balance so the best place >>> to choose to migrate them is during their wake up. The decision is in O(1) >>> as >>> we only check again one buddy CPU >> >> Just have a little worry about the scalability on a big machine, like on >> a 4 sockets NUMA machine * 8 cores * HT machine, the buddy cpu in whole >> system need care 64 LCPUs. and in your case cpu0 just care 4 LCPU. That >> is different on task distribution decision. > > The buddy CPU should probably not be the same for all 64 LCPU it > depends on where it's worth packing small tasks Do you have further ideas for buddy cpu on such example? > > Which kind of sched_domain configuration have you for such system ? > and how many sched_domain level have you ? it is general X86 domain configuration. with 4 levels, sibling/core/cpu/numa. > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v2 3/6] sched: pack small tasks
On 13 December 2012 15:25, Alex Shi wrote: > On 12/13/2012 06:11 PM, Vincent Guittot wrote: >> On 13 December 2012 03:17, Alex Shi wrote: >>> On 12/12/2012 09:31 PM, Vincent Guittot wrote: During the creation of sched_domain, we define a pack buddy CPU for each CPU when one is available. We want to pack at all levels where a group of CPU can be power gated independently from others. On a system that can't power gate a group of CPUs independently, the flag is set at all sched_domain level and the buddy is set to -1. This is the default behavior. On a dual clusters / dual cores system which can power gate each core and cluster independently, the buddy configuration will be : | Cluster 0 | Cluster 1 | | CPU0 | CPU1 | CPU2 | CPU3 | --- buddy | CPU0 | CPU0 | CPU0 | CPU2 | Small tasks tend to slip out of the periodic load balance so the best place to choose to migrate them is during their wake up. The decision is in O(1) as we only check again one buddy CPU >>> >>> Just have a little worry about the scalability on a big machine, like on >>> a 4 sockets NUMA machine * 8 cores * HT machine, the buddy cpu in whole >>> system need care 64 LCPUs. and in your case cpu0 just care 4 LCPU. That >>> is different on task distribution decision. >> >> The buddy CPU should probably not be the same for all 64 LCPU it >> depends on where it's worth packing small tasks > > Do you have further ideas for buddy cpu on such example? yes, I have several ideas which were not really relevant for small system but could be interesting for larger system We keep the same algorithm in a socket but we could either use another LCPU in the targeted socket (conf0) or chain the socket (conf1) instead of packing directly in one LCPU The scheme below tries to summaries the idea: Socket | socket 0 | socket 1 | socket 2 | socket 3 | LCPU| 0 | 1-15 | 16 | 17-31 | 32 | 33-47 | 48 | 49-63 | buddy conf0 | 0 | 0| 1 | 16| 2 | 32| 3 | 48| buddy conf1 | 0 | 0| 0 | 16| 16 | 32| 32 | 48| buddy conf2 | 0 | 0| 16 | 16| 32 | 32| 48 | 48| But, I don't know how this can interact with NUMA load balance and the better might be to use conf3. >> >> Which kind of sched_domain configuration have you for such system ? >> and how many sched_domain level have you ? > > it is general X86 domain configuration. with 4 levels, > sibling/core/cpu/numa. >> ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v2 3/6] sched: pack small tasks
On 13 December 2012 15:53, Vincent Guittot wrote: > On 13 December 2012 15:25, Alex Shi wrote: >> On 12/13/2012 06:11 PM, Vincent Guittot wrote: >>> On 13 December 2012 03:17, Alex Shi wrote: On 12/12/2012 09:31 PM, Vincent Guittot wrote: > During the creation of sched_domain, we define a pack buddy CPU for each > CPU > when one is available. We want to pack at all levels where a group of CPU > can > be power gated independently from others. > On a system that can't power gate a group of CPUs independently, the flag > is > set at all sched_domain level and the buddy is set to -1. This is the > default > behavior. > On a dual clusters / dual cores system which can power gate each core and > cluster independently, the buddy configuration will be : > > | Cluster 0 | Cluster 1 | > | CPU0 | CPU1 | CPU2 | CPU3 | > --- > buddy | CPU0 | CPU0 | CPU0 | CPU2 | > > Small tasks tend to slip out of the periodic load balance so the best > place > to choose to migrate them is during their wake up. The decision is in > O(1) as > we only check again one buddy CPU Just have a little worry about the scalability on a big machine, like on a 4 sockets NUMA machine * 8 cores * HT machine, the buddy cpu in whole system need care 64 LCPUs. and in your case cpu0 just care 4 LCPU. That is different on task distribution decision. >>> >>> The buddy CPU should probably not be the same for all 64 LCPU it >>> depends on where it's worth packing small tasks >> >> Do you have further ideas for buddy cpu on such example? > > yes, I have several ideas which were not really relevant for small > system but could be interesting for larger system > > We keep the same algorithm in a socket but we could either use another > LCPU in the targeted socket (conf0) or chain the socket (conf1) > instead of packing directly in one LCPU > > The scheme below tries to summaries the idea: > > Socket | socket 0 | socket 1 | socket 2 | socket 3 | > LCPU| 0 | 1-15 | 16 | 17-31 | 32 | 33-47 | 48 | 49-63 | > buddy conf0 | 0 | 0| 1 | 16| 2 | 32| 3 | 48| > buddy conf1 | 0 | 0| 0 | 16| 16 | 32| 32 | 48| > buddy conf2 | 0 | 0| 16 | 16| 32 | 32| 48 | 48| > > But, I don't know how this can interact with NUMA load balance and the > better might be to use conf3. I mean conf2 not conf3 > >>> >>> Which kind of sched_domain configuration have you for such system ? >>> and how many sched_domain level have you ? >> >> it is general X86 domain configuration. with 4 levels, >> sibling/core/cpu/numa. >>> ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] linux-linaro kernel schedule for 12.12
On 12/13/2012 03:53 AM, Tushar Behera wrote: * Android kernel doesn't compile because of some change in gpu/ion. Even after adding fixes for compilation errors there is crash during booting, so didn't push those fixes. Tushar: Sorry about this. I'll try to take a look at the compilation issues today (mind sending me your config?). I've not yet applied the patches you sent as I wanted to double check that AOSP didn't have more official fixes. Will try to get this sorted here quickly. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] cpufreq: interactive: fix racy timer stopping
From: Nicolas Pitre
Relying on pcpu->governor_enabled alone to ensure proper shutdown
of the governor activities is flawed. The following race is perfectly
possible:
CPU0|CPU2
+
|cpufreq_interactive_timer()
cpufreq_governor_interactive(GOV_STOP) |if (!pcpu->governor_enabled)
pcpu->governor_enabled = 0; |return; [untaken]
smp_wmb(); |[...]
del_timer_sync(&pcpu->cpu_timer); |cpufreq_interactive_timer_resched()
|mod_timer_pinned(&pcpu->cpu_timer)
Result: timer is pending again. It is also possible for
del_timer_sync() to race against the invocation of the idle notifier
callback which also has the potential to reactivate the timer.
To fix this issue, a read-write semaphore is used. Multiple readers are
allowed as long as pcpu->governor_enabled is true. However it can be
moved to false only after taking a write semaphore which would wait for
any on-going asynchronous activities to complete and prevent any more of
those activities to be initiated.
Signed-off-by: Nicolas Pitre
---
drivers/cpufreq/cpufreq_interactive.c | 38 ++-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_interactive.c
b/drivers/cpufreq/cpufreq_interactive.c
index c82d9fe..061af7f 100644
--- a/drivers/cpufreq/cpufreq_interactive.c
+++ b/drivers/cpufreq/cpufreq_interactive.c
@@ -21,14 +21,13 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
#include
#include
#include
-#include
#include
#include
@@ -50,6 +49,7 @@ struct cpufreq_interactive_cpuinfo {
unsigned int floor_freq;
u64 floor_validate_time;
u64 hispeed_validate_time;
+ struct rw_semaphore mutex;
int governor_enabled;
};
@@ -138,8 +138,8 @@ static void cpufreq_interactive_timer(unsigned long data)
unsigned int index;
unsigned long flags;
- smp_rmb();
-
+ if (!down_read_trylock(&pcpu->mutex))
+ return;
if (!pcpu->governor_enabled)
goto exit;
@@ -258,6 +258,7 @@ rearm:
}
exit:
+ up_read(&pcpu->mutex);
return;
}
@@ -267,8 +268,12 @@ static void cpufreq_interactive_idle_start(void)
&per_cpu(cpuinfo, smp_processor_id());
int pending;
- if (!pcpu->governor_enabled)
+ if (!down_read_trylock(&pcpu->mutex))
+ return;
+ if (!pcpu->governor_enabled) {
+ up_read(&pcpu->mutex);
return;
+ }
pending = timer_pending(&pcpu->cpu_timer);
@@ -298,6 +303,7 @@ static void cpufreq_interactive_idle_start(void)
}
}
+ up_read(&pcpu->mutex);
}
static void cpufreq_interactive_idle_end(void)
@@ -305,8 +311,12 @@ static void cpufreq_interactive_idle_end(void)
struct cpufreq_interactive_cpuinfo *pcpu =
&per_cpu(cpuinfo, smp_processor_id());
- if (!pcpu->governor_enabled)
+ if (!down_read_trylock(&pcpu->mutex))
+ return;
+ if (!pcpu->governor_enabled) {
+ up_read(&pcpu->mutex);
return;
+ }
/* Arm the timer for 1-2 ticks later if not already. */
if (!timer_pending(&pcpu->cpu_timer)) {
@@ -317,6 +327,8 @@ static void cpufreq_interactive_idle_end(void)
del_timer(&pcpu->cpu_timer);
cpufreq_interactive_timer(smp_processor_id());
}
+
+ up_read(&pcpu->mutex);
}
static int cpufreq_interactive_speedchange_task(void *data)
@@ -351,10 +363,12 @@ static int cpufreq_interactive_speedchange_task(void
*data)
unsigned int max_freq = 0;
pcpu = &per_cpu(cpuinfo, cpu);
- smp_rmb();
-
- if (!pcpu->governor_enabled)
+ if (!down_read_trylock(&pcpu->mutex))
+ continue;
+ if (!pcpu->governor_enabled) {
+ up_read(&pcpu->mutex);
continue;
+ }
for_each_cpu(j, pcpu->policy->cpus) {
struct cpufreq_interactive_cpuinfo *pjcpu =
@@ -371,6 +385,8 @@ static int cpufreq_interactive_speedchange_task(void *data)
trace_cpufreq_interactive_setspeed(cpu,
pcpu->target_freq,
pcpu->policy->cur);
+
+ up_read(&pcpu->mutex);
}
}
@@ -690,9 +706,10 @@ static int cpufreq_governor_interactive(struct
cpufreq_policy *policy,
case CPUFREQ_GOV_STOP:
for_each_cpu(j, policy->cpus) {
Re: [ANNOUNCE] linux-linaro kernel schedule for 12.12
On 12/13/2012 03:53 AM, Tushar Behera wrote: * Android kernel doesn't compile because of some change in gpu/ion. Even after adding fixes for compilation errors there is crash during booting, so didn't push those fixes. Hey Tushar, After looking at the issues you pointed out, I've got some alternative patches to try to resolve the ION issues. Would you mind trying them out? I don't have any ion supported hardware around, so I'm not able to actually test if they're ok, but they do build. See the changes here: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/tushar-test Or fetch them here: git://git.linaro.org/people/jstultz/android.git tushar-test If they work for you, I'll push them to the Linaro+Android tree. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v2 3/6] sched: pack small tasks
On 12/13/2012 11:48 PM, Vincent Guittot wrote: > On 13 December 2012 15:53, Vincent Guittot wrote: >> On 13 December 2012 15:25, Alex Shi wrote: >>> On 12/13/2012 06:11 PM, Vincent Guittot wrote: On 13 December 2012 03:17, Alex Shi wrote: > On 12/12/2012 09:31 PM, Vincent Guittot wrote: >> During the creation of sched_domain, we define a pack buddy CPU for each >> CPU >> when one is available. We want to pack at all levels where a group of >> CPU can >> be power gated independently from others. >> On a system that can't power gate a group of CPUs independently, the >> flag is >> set at all sched_domain level and the buddy is set to -1. This is the >> default >> behavior. >> On a dual clusters / dual cores system which can power gate each core and >> cluster independently, the buddy configuration will be : >> >> | Cluster 0 | Cluster 1 | >> | CPU0 | CPU1 | CPU2 | CPU3 | >> --- >> buddy | CPU0 | CPU0 | CPU0 | CPU2 | >> >> Small tasks tend to slip out of the periodic load balance so the best >> place >> to choose to migrate them is during their wake up. The decision is in >> O(1) as >> we only check again one buddy CPU > > Just have a little worry about the scalability on a big machine, like on > a 4 sockets NUMA machine * 8 cores * HT machine, the buddy cpu in whole > system need care 64 LCPUs. and in your case cpu0 just care 4 LCPU. That > is different on task distribution decision. The buddy CPU should probably not be the same for all 64 LCPU it depends on where it's worth packing small tasks >>> >>> Do you have further ideas for buddy cpu on such example? >> >> yes, I have several ideas which were not really relevant for small >> system but could be interesting for larger system >> >> We keep the same algorithm in a socket but we could either use another >> LCPU in the targeted socket (conf0) or chain the socket (conf1) >> instead of packing directly in one LCPU >> >> The scheme below tries to summaries the idea: >> >> Socket | socket 0 | socket 1 | socket 2 | socket 3 | >> LCPU| 0 | 1-15 | 16 | 17-31 | 32 | 33-47 | 48 | 49-63 | >> buddy conf0 | 0 | 0| 1 | 16| 2 | 32| 3 | 48| >> buddy conf1 | 0 | 0| 0 | 16| 16 | 32| 32 | 48| >> buddy conf2 | 0 | 0| 16 | 16| 32 | 32| 48 | 48| >> >> But, I don't know how this can interact with NUMA load balance and the >> better might be to use conf3. > > I mean conf2 not conf3 So, it has 4 levels 0/16/32/ for socket 3 and 0 level for socket 0, it is unbalanced for different socket. And the ground level has just one buddy for 16 LCPUs - 8 cores, that's not a good design, consider my previous examples: if there are 4 or 8 tasks in one socket, you just has 2 choices: spread them into all cores, or pack them into one LCPU. Actually, moving them just into 2 or 4 cores maybe a better solution. but the design missed this. Obviously, more and more cores is the trend on any kinds of CPU, the buddy system seems hard to catch up this. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Patch for YAML test definitions
On Thursday 13 December 2012 03:18 PM, Senthil Kumaran wrote: I converted lava-test test definitions to work on lava-test-shell with the new YAML format. These converted tests are mostly from https://code.launchpad.net/~linaro-foundations In addition to this, I would like this trivial change given in the attached patch to be merged in branch lp:~linaro-foundations/lava-test/bootchartscript This change is to accommodate attaching the result of the bootchart test to a file and upload it to the lava dashboard. Thank You. -- Senthil Kumaran S http://www.stylesen.org/ http://www.sasenthilkumaran.com/ === modified file 'bootchartscript.sh' --- bootchartscript.sh 2011-07-22 19:25:12 + +++ bootchartscript.sh 2012-12-13 16:41:47 + @@ -24,5 +24,5 @@ BASE="/var/log/bootchart/$base-$count" TARBALL="$BASE.tgz" -python $PWD/bootchartscript/bootcharttest.py $TARBALL -q +python $PWD/bootchartscript/bootcharttest.py $TARBALL -q > bootchart.log ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v2 3/6] sched: pack small tasks
On 12/14/2012 12:45 PM, Mike Galbraith wrote: >> > Do you have further ideas for buddy cpu on such example? >>> > > >>> > > Which kind of sched_domain configuration have you for such system ? >>> > > and how many sched_domain level have you ? >> > >> > it is general X86 domain configuration. with 4 levels, >> > sibling/core/cpu/numa. > CPU is a bug that slipped into domain degeneration. You should have > SIBLING/MC/NUMA (chasing that down is on todo). Maybe. the CPU/NUMA is different on domain flags, CPU has SD_PREFER_SIBLING. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Patch for YAML test definitions
On 14 December 2012 07:25, Senthil Kumaran wrote: > accommodate attaching the result of the bootchart test to a file and upload > it to the lava dashboard. Commited. Thanks. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v2 3/6] sched: pack small tasks
On 12/14/2012 03:45 PM, Mike Galbraith wrote: > On Fri, 2012-12-14 at 14:36 +0800, Alex Shi wrote: >> On 12/14/2012 12:45 PM, Mike Galbraith wrote: > Do you have further ideas for buddy cpu on such example? >>> >>> Which kind of sched_domain configuration have you for such system ? >>> and how many sched_domain level have you ? > > it is general X86 domain configuration. with 4 levels, > sibling/core/cpu/numa. >>> CPU is a bug that slipped into domain degeneration. You should have >>> SIBLING/MC/NUMA (chasing that down is on todo). >> >> Maybe. >> the CPU/NUMA is different on domain flags, CPU has SD_PREFER_SIBLING. > > What I noticed during (an unrelated) bisection on a 40 core box was > domains going from so.. > > 3.4.0-bisect (virgin) > [5.056214] CPU0 attaching sched-domain: > [5.065009] domain 0: span 0,32 level SIBLING > [5.075011] groups: 0 (cpu_power = 589) 32 (cpu_power = 589) > [5.088381] domain 1: span > 0,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76 level MC > [5.107669]groups: 0,32 (cpu_power = 1178) 4,36 (cpu_power = 1178) > 8,40 (cpu_power = 1178) 12,44 (cpu_power = 1178) > 16,48 (cpu_power = 1177) 20,52 (cpu_power = 1178) > 24,56 (cpu_power = 1177) 28,60 (cpu_power = 1177) > 64,72 (cpu_power = 1176) 68,76 (cpu_power = 1176) > [5.162115]domain 2: span 0-79 level NODE > [5.171927] groups: > 0,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76 (cpu_power = 11773) > > 1,5,9,13,17,21,25,29,33,37,41,45,49,53,57,61,65,69,73,77 (cpu_power = 11772) > > 2,6,10,14,18,22,26,30,34,38,42,46,50,54,58,62,66,70,74,78 (cpu_power = 11773) > > 3,7,11,15,19,23,27,31,35,39,43,47,51,55,59,63,67,71,75,79 (cpu_power = 11770) > > ..to so, which looks a little bent. CPU and MC have identical spans, so > CPU should have gone away, as it used to do. > better to remove one, and believe you can make it. :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
