| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4F46F105.2000702@linux.vnet.ibm.com>
Date: Fri, 24 Feb 2012 10:08:05 +0800
From: Michael Wang <wangyun@...ux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC: Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5] sched: Avoid unnecessary work in reweight_entity
On 02/23/2012 06:40 PM, Michael Wang wrote:
> On 02/20/2012 09:08 PM, Peter Zijlstra wrote:
>
> Hi, Peter
>
> Sorry for reply so late, I was blocked by some issue army while setup the
> testing environment.
>
>> On Sat, 2012-02-18 at 09:43 +0800, Michael Wang wrote:
>>> And as reight_entity is invoked very often, I think this patch can do some help to the
>>> performance, although there are no numbers, we can prove it logically :)
>>
>> Well, you're probably right (although I think you completely ignored the
>> optimizing compiler), but still it would be good to get some numbers to
>> confirm reality :-)
>
>
> That's right, if consider the compiler's optimization, the logic improvements
> I listed may not be true...
>
>>
>
>> Just pick your favourite cgroup workload/benchmark and run a pre/post
>> comparison, possible using perf record.
>>
>> If all squares up you should see an improvement in your benchmark score
>> as well as see a reduction in time spend in the function you're
>> patching.
>
>
> So I created a cpuset cgroup 'rg1' and his sub memory group 'sub',
> attached current shell to 'sub', then use 'time make kernel' as benchmark.
>
> Below is the test result:
>
> 'time make':
> old
> real: 87m53.804s user: 66m41.886s sys: 11m51.792s
> new
> real: 86m8.485s user: 65m49.211s sys: 11m47.264s
>
> 'time make -j14':
> old:
> real: 42m43.825s user: 124m13.726s sys: 17m57.183s
> new
> real: 39m0.072s user: 114m33.258s sys: 15m30.662s
>
Hi, Peter
Someone notify me that this result is ridiculous, I should have done more test,
not just once, this is really my fault, please give me more time, I will back
with more data so we can use average number.
Regards,
Michael Wang
> I also try to use 'perf sched record', but I can only record few seconds time,
> otherwise it will be too big and report some error, as the record time is too
> short, results are very different from each other, I failed to use them to prove
> the patch:(
>
> I also have try to use some other method, I moved 'reweight_entity' and related
> functions to user space, and invoke it 10000000 times in 'main', I have append
> part of the code (really raw...) in the end.
>
> Three times output is:
>
> old:
> real 0m0.715s 0m0.710s 0m0.739s
> user 0m0.716s 0m0.708s 0m0.736s
> sys 0m0.000s 0m0.000s 0m0.000s
>
> new:
> real 0m0.318s 0m0.308s 0m0.317s
> user 0m0.316s 0m0.304s 0m0.316s
> sys 0m0.000s 0m0.000s 0m0.000s
>
> It seems like that new code can save more then half execution time, but also we
> can see, after calculation, what I have done can only save 0.04ns(too small...).
>
> The user space test result is not accurate but at least we can know new code is
> faster then old.
>
> Please tell me if we need to do some thing else, and thanks for your suggestion :)
>
> Regards,
> Michael Wang
>
>
>
> User space code:
>
> void
> account_entity_enqueue(struct cfs_rq *cfs_rq, struct sched_entity *se)
> {
> update_load_add(&cfs_rq->load, se->load.weight);
> if (1)
> update_load_add(&cfs_rq->load, se->load.weight);
> if (1) {
> add_cfs_task_weight(cfs_rq, se->load.weight);
> list_add(&se->group_node, &cfs_rq->tasks);
> }
> cfs_rq->nr_running++;
> }
>
> void
> account_entity_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se)
> {
> update_load_sub(&cfs_rq->load, se->load.weight);
> if (1)
> update_load_sub(&cfs_rq->load, se->load.weight);
> if (1) {
> add_cfs_task_weight(cfs_rq, -se->load.weight);
> list_del_init(&se->group_node);
> }
> cfs_rq->nr_running--;
> }
>
> void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
> unsigned long weight)
> {
> if (1) {
> account_entity_dequeue(cfs_rq, se);
> }
>
> update_load_set(&se->load, weight);
>
> if (1)
> account_entity_enqueue(cfs_rq, se);
> }
>
> void reweight_entity_new(struct cfs_rq *cfs_rq, struct sched_entity *se,
> unsigned long weight)
> {
> if (1) {
> update_load_add(&cfs_rq->load, weight - se->load.weight);
> if(1)
> update_load_add(&cfs_rq->load, weight -
> se->load.weight);
> if(1)
> add_cfs_task_weight(cfs_rq, weight
> -se->load.weight);
> }
> update_load_set(&se->load, weight);
> }
>
> int main()
> {
> struct cfs_rq cfsrq;
> struct sched_entity se;
> memset(&cfsrq, 0, sizeof(struct cfs_rq));
> memset(&se, 0, sizeof(struct sched_entity));
> INIT_LIST_HEAD(&se.group_node);
> INIT_LIST_HEAD(&cfsrq.tasks);
> int i = 10000000;
> while(i) {
> i--;
> reweight_entity_new(&cfsrq, &se, 10);
> //reweight_entity(&cfsrq, &se, 10);
> }
> }
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists