Fwd: 在benzina手机上的测试
XingChao Wang
--wang xingchao
---------- Forwarded message ----------
From: XingChao Wang <wxc...@gmail.com>
Date: 2009/9/6
Subject: Re: 在benzina手机上的测试
To: 伊泽 <wxc...@gmail.com>, hamod...@borqs.com
调度这部分真是难啊，，，，从这一部分测试就可以看得出来。。。附上我的测试和编译code
thanks
--wang xingchao
2009/9/6 XingChao Wang <wxc...@gmail.com>
>
> 在phone上更改/proc/sys/kernel/sched_runtime(950ms default)，then test it.
>
> for ubuntu,it faild to change that,but '-1' is okay.
>
> reading code(sched_rt_handler) to get why.
> thanks
> --wang xingchao
>
>
> 2009/9/6 XingChao Wang <wxc...@gmail.com>
>>
>> arm-linux-gcc ani.c -lpthread 测试后，在benzina /data目录下进行测试，log 如下
>>
>> /data # ./ani
>> Usage: ./ani <core-ID>
>> /data # ./ani 0
>> new nice value for regular thread=-20
>> regular thread dispatch(0)
>> start reg_count=13857579920108844
>> [ 7099.953125] msldl_pm: received wakeup ack but no pending tx..
>> [ 7161.164062] gpio_keys_isr: gpio key keycode: 158
>> [ 7161.367187] gpio_keys_isr: gpio key keycode: 158
>> [ 7164.000000] android_power: wakeup (2->0) at 6822166809379 (2009-09-06 08:32:16.948425293 UTC)
>> [ 7170.656250] gpio_keys_isr: gpio key keycode: 158
>> [ 7170.859375] gpio_keys_isr: gpio key keycode: 158
>> [ 7171.406250] gpio_keys_isr: gpio key keycode: 158
>> [ 7171.632812] gpio_keys_isr: gpio key keycode: 158
>> [ 7181.960937] micco_w1_read_byte timeout = 0
>> [ 7182.000000] reset value: 0
>> [ 7187.156250] gpio_keys_isr: gpio key keycode: 158
>> [ 7187.351562] gpio_keys_isr: gpio key keycode: 158
>> [ 7187.578125] gpio_keys_isr: gpio key keycode: 158
>> [ 7187.781250] gpio_keys_isr: gpio key keycode: 158
>> [ 7188.023437] gpio_keys_isr: gpio key keycode: 158
>> [ 7188.203125] gpio_keys_isr: gpio key keycode: 158
>> [ 7188.507812] gpio_keys_isr: gpio key keycode: 158
>> [ 7188.679687] gpio_keys_isr: gpio key keycode: 158
>> [ 7192.031250] gpio_keys_isr: gpio key keycode: 158
>> [ 7192.210937] gpio_keys_isr: gpio key keycode: 158
>> [ 7192.359375] gpio_keys_isr: gpio key keycode: 158
>> [ 7192.515625] gpio_keys_isr: gpio key keycode: 158
>> [ 7192.632812] gpio_keys_isr: gpio key keycode: 158
>> [ 7192.796875] gpio_keys_isr: gpio key keycode: 158
>> [ 7203.445312] gpio_keys_isr: gpio key keycode: 158
>> [ 7203.710937] gpio_keys_isr: gpio key keycode: 158
>> [ 7203.914062] gpio_keys_isr: gpio key keycode: 158
>> [ 7204.085937] gpio_keys_isr: gpio key keycode: 158
>> [ 7209.984375] android_power: sleep (0->2) at 6867837250053 (2009-09-06 08:33:02.618865967 UTC)
>> [ 7212.984375] will reset touch point...
>> [ 7212.984375] before lock: x1: 3024, y1: 1727, finger_st1: 1; x2: 6336, y2: 3663, finger_st2: 0
>> [ 7212.992187] after lock: x1: 3024, y1: 1727, finger_st1: 1; x2: 6336, y2: 3663, finger_st2: 0
>> [ 7218.320312] gpio_keys_isr: gpio key keycode: 158
>> [ 7218.523437] gpio_keys_isr: gpio key keycode: 158
>> [ 7219.976562] android_power: wakeup (2->0) at 6877729095756 (2009-09-06 08:33:12.510711670 UTC)
>> [ 7221.945312] reset value: 0
>> [ 7226.976562] micco_w1_read_byte timeout = 0
>> [ 7261.953125] cleartouch: device status: 0x0
>> [ 7263.976562] micco_w1_read_byte timeout = 0
>>
>> RT thread has terminated
>> end reg_count=219849064740917248
>> delta reg count = 205991484880392079
>> fifo count = 4617748090962939904
>> % = 2.233364
>> [ 7272.695312] msldl_pm: received wakeup ack but no pending tx..
>> [ 7279.835937] msldl_pm: received wakeup ack but no pending tx..
>> [ 7286.265625] msldl_pm: received wakeup ack but no pending tx..
>> [ 7291.390625] android_power: sleep (0->2) at 6948356598197 (2009-09-06 08:34:23.138214111 UTC)
>>
>> regular thread has terminated
>>
>> 在此期间，手机僵死....只响应中断
>>
>> thanks
>> --wang xingchao
>>
>>
>> ---------- Forwarded message ----------
>> From: Anirban Sinha <ASi...@zeugmasystems.com>
>> Date: 2009/9/5
>> Subject: question on sched-rt group allocation cap: sched_rt_runtime_us
>> To: linux-...@vger.kernel.org, Ingo Molnar <mi...@elte.hu>
>>
>>
>> Hi Ingo and rest:
>>
>> I have been playing around with the sched_rt_runtime_us cap that can be
>> used to limit the amount of CPU time allocated towards scheduling rt
>> group threads. I am using 2.6.26 with CONFIG_GROUP_SCHED disabled (we
>> use only the root user in our embedded setup). I have no other CPU
>> intensive workloads (RT or otherwise) running on my system. I have
>> changed no other scheduling parameters from /proc.
>>
>> I have written a small test program that:
>>
>> (a) forks two threads, one SCHED_FIFO and one SCHED_OTHER (this thread
>> is reniced to -20) and ties both of them to a specific core.
>> (b) runs both the threads in a tight loop (same number of iterations for
>> both threads) until the SCHED_FIFO thread terminates.
>> (c) calculates the number of completed iterations of the regular
>> SCHED_OTHER thread against the fixed number of iterations of the
>> SCHED_FIFO thread. It then calculates a percentage based on that.
>>
>> I am running the above workload against varying sched_rt_runtime_us
>> values (200 ms to 700 ms) keeping the sched_rt_period_us constant at
>> 1000 ms. I have also experimented a little bit by decreasing the value
>> of sched_rt_period_us (thus increasing the sched granularity) with no
>> apparent change in behavior.
>>
>> My observations are listed in tabular form:
>>
>> Ratio of # of completed iterations of reg thread /
>> sched_rt_runtime_us / # of iterations of RT thread (in %)
>> sched_rt_runtime_us
>>
>> 0.2 100 % (regular thread completed all its
>> iterations).
>> 0.3 73 %
>> 0.4 45 %
>> 0.5 17 %
>> 0.6 0 % (SCHED_OTHER thread completely throttled.
>> Never ran)
>> 0.7 0 %
>>
>> This result kind of baffles me. Even when we cap the RT group to a
>> fraction of 0.6 of overall CPU time, the rest 0.4 \should\ still be
>> available for running regular threads. So my SCHED_OTHER \should\ make
>> some progress as opposed to being completely throttled. Similarly, with
>> any fraction less than 0.5, the SCHED_OTHER should complete before
>> SCHED_FIFO.
>>
>> I do not have an easy way to verify my results over the latest kernel
>> (2.6.31). Was there any regressions in the scheduling subsystem in
>> 2.6.26? Can this behavior be explained? Do we need to tweak any other
>> /proc parameters?
>>
>> Cheers,
>>
>> Ani
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majo...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>