|
CONFIG_SCHED_DEBUG
@damentz: Could we have CONFIG_SCHED_DEBUG=y, please?
This would allow to tune the latency of the scheduler via userspace. Back to top |
|||||
|
This is a debug option that not many people use or are even aware that exists. Could you run a quick benchmark showing the performance penalty for enabling this?
fester, another kernel hacker that hangs in #smxi, recommends this quick tool that can compute pi up to the (n)th digit. You can grab it here -> liquorix.net/misc/pi.gz Just gunzip that and set the executable bit and run it with the parameter 20. How long this takes depends on your processor, but you can increase and decrease the amount of digits you compute up to by changing 20 to another value. Obviously, the smaller the number, the faster the benchmark but the more inconsistent your results will be on each consecutive run. Just for the record, here's my output to reference: :: Code :: $ ./pi 20
Version 2.0 of the super_pi for Linux OS Fortran source program was translated into C program with version 19981204 of f2c, then generated C source program was optimized manually. pgcc 3.2-3 with compile option of "-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant" was used for the compilation. ------ Started super_pi run : Sat Jul 11 12:42:02 CDT 2009 Start of PI calculation up to 1048576 decimal digits End of initialization. Time= 0.269 Sec. I= 1 L= 0 Time= 0.726 Sec. I= 2 L= 0 Time= 0.828 Sec. I= 3 L= 1 Time= 0.837 Sec. I= 4 L= 2 Time= 0.838 Sec. I= 5 L= 5 Time= 0.832 Sec. I= 6 L= 10 Time= 0.862 Sec. I= 7 L= 21 Time= 0.836 Sec. I= 8 L= 43 Time= 0.831 Sec. I= 9 L= 87 Time= 0.836 Sec. I=10 L= 174 Time= 0.838 Sec. I=11 L= 349 Time= 0.830 Sec. I=12 L= 698 Time= 0.836 Sec. I=13 L= 1396 Time= 0.832 Sec. I=14 L= 2794 Time= 0.830 Sec. I=15 L= 5588 Time= 0.832 Sec. I=16 L= 11176 Time= 0.829 Sec. I=17 L= 22353 Time= 0.808 Sec. I=18 L= 44707 Time= 0.785 Sec. I=19 L= 89415 Time= 0.728 Sec. End of main loop End of calculation. Time= 16.479 Sec. End of data output. Time= 0.103 Sec. Total calculation(I/O) time= 16.582( 0.598) Sec. ------ Ended super_pi run : Sat Jul 11 12:42:19 CDT 2009 Back to top |
|||||
|
Results (all in single user mode, vanilla 2.6.30.1, gcc-3.4, minimalistic kernel config, Pentium III@866MHz, pi 20, Total calculation(I/O) time):
1) without CONFIG_SCHED_DEBUG: first run: 128.270s second run: 128.324s 2) with CONFIG_SCHED_DEBUG=y: first run: 128.391s second run: 128.347s Conclusions: 1) Throughput penalty is probably below 0.1% here. 2) Concerning this benchmark, damentz' computer is nearly 8 times faster than mine (What is it, by the way?). He should grant me access to his machine, so I don't have to spend that much time for doing kernel compilation and benchmarks ;-) Back to top |
|||||
|
Looks reasonable, I'll enable it on the next kernel release when enough changes have incurred, thanks!
And here's my laptop specs: :: Code :: $ inxi -v5
System: Host damentz64 Kernel 2.6.30-1.dmz.3-liquorix-amd64 x86_64 (64 bit) Distro Debian GNU/Linux squeeze/sid CPU: Dual core Intel Core2 Duo T7500 (SMP) cache 4096 KB flags (sse3 nx lm vmx) Clock Speeds: (1) 800.00 MHz (2) 2201.00 MHz Graphics: Card nVidia G86 [GeForce 8400M GS] X.Org 1.6.1.901 Res: 2880x900@50.0hz GLX Renderer GeForce 8400M GS/PCI/SSE2 GLX Version 3.0.0 NVIDIA 185.18.14 Audio: Card-1 Intel 82801H (ICH8 Family) HD Audio Controller driver HDA Intel Card-2 Logitech Inc. USB Headset driver snd-usb-audio Sound: Advanced Linux Sound Architecture Version 1.0.20 Network: Card-1 Broadcom NetLink BCM5906M Fast Ethernet PCI Express driver tg3 Card-2 Intel PRO/Wireless 3945ABG [Golan] Network Connection driver iwl3945 Disks: HDD Total Size: 820.2GB (76.1% used) 1: ST9320421AS 2: 5000AAV External Partition: ID:/ size: 16G used: 7.5G (52%) ID:/boot size: 114M used: 64M (60%) ID:/home size: 277G used: 224G (82%) ID:swap-1 size: 0.90GB used: 0.00GB (0%) ID:swap-2 size: 2.05GB used: 0.00GB (0%) Info: Processes 180 Uptime 9:54 Memory 862.4/3965.8MB Client Shell inxi 1.0.17 Fastest CPU dell would let me put in their laptop at that time :) Back to top |
|||||
|
Hey, I disabled the CONFIG_SCHED_DEBUG for now - the zen kernels include Zen-Tune which allows you to set the scheduler wakeup/latency granularity without the debugging overhead.
I'll leave this option disabled until I can patch kernel/sysctl.c to use my preferred scheduler defaults. Less people use these debugging sysctls to make it worth dropping my modified scheduler latency configuration at the moment. Back to top |
|||||
|
Just two quick thoughts about it:
1. You used the phrase "debugging overhead". Contrary to what the name suggests, CONFIG_SCHED_DEBUG hasn't to do anything with debugging, in my opinion. As it can be seen in the LKML archives, Linus wants a uniform untunable scheduler for the typical enduser. I assume, that's the reason why the access to the scheduler tunables from user space is disabled by default and can only be enabled in a dark and dangerous place like the kernel hacking menu. 2. There is no need to disable CONFIG_SCHED_DEBUG. It can coexist with Zen-Tune, right? There is also no performance gain in disabling it. But there is huge downside in taking away the freedom of the users to make their choices. Back to top |
|||||
|
This debugging option creates the file /proc/sched_debug which is updated very frequently.
And CONFIG_SCHED_DEBUG is typically enabled on generic distribution kernels that are not optimized for any particular task. In my situation, I'm trying to create a better out of the box experience - post install configuration will not do. Like I said, when I figure out how to set default values for the sysctl userspace, I'll reenable it. Back to top |
|||||
|
:: Quote :: This debugging option creates the file /proc/sched_debug which is updated very frequently.And you think this overhead is meaningful? :: Quote :: Like I said, when I figure out how to set default values for the sysctl userspace, I'll reenable it.The default values can be found easily. They are in kernel/sched_fair.c and kernel/sched_features.h . I am a little confused. Why don't we currently have all of these nice /proc/sys/kernel/sched_ tunables? Would you mind telling me exactly where the problem is? Back to top |
|||||
|
The default values are found in those two files, but if you look through the kernel source - you'll notice I'm already using them. However, CONFIG_SCHED_DEBUG grabs values from elsewhere, hence your confusion.
This is a performance kernel tuned for defaults that enhance desktop performance and latency - by enabling CONFIG_SCHED_DEBUG, I lose control of the latency aspect and the advantage to using the Liquorix kernel over a standard distro kernel is reduced. I understand your concern, but default tuning is higher priority than the wiggle room for a minority of users. But a question, if you require this much control, what is stopping you from creating your own kernel? Most people would build their own kernel if they require special tuning for their unique tasks. Back to top |
|||||
|
:: Quote :: linux-liquorix-2.6 (2.6.30-24) unstable; urgency=low
* increased target latency to 24ms :: Quote :: linux-liquorix-2.6 (2.6.30-22) unstable; urgency=low
* changed config - sched_min_granularity_ns = 4000000 - sched_wakeup_granularity_ns = 4000000 - sched_latency_ns = 16000000 I am currently looking at the 2.6.30-24 sources. All those *CUSTOM_SCHED_* and *CUSTOM_VM_* config options in the Zen-Tune menu are fakes, they have no effect. So there probably is only little need to optimize them any further ;-) Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||