update: preemptive kernel for O(1) sched
PATCH 1/1 update: preemptive kernel for O(1) sched
This is an update of the fully preemptible kernel patch for use with Ingo Molnar's O(1) scheduler.
A few users reported oopses which I hope this update will address. George Anzinger and I also worked in some optimizations, most notably to preempt_schedule. More to come.
An updated preempt-kernel for 2.5.2-pre11:
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.5/preempt-kernel-rml-2.5.2-pre11-2.patch
An updated preempt-kernel for 2.4.18-pre3 + O1-H7:
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/ingo-O1-sched/preempt-kernel-rml-2.4.18-pre3-ingo-2.patch
Again, the 2.5 patch is for use with the stock version of Ingo's scheduler. Updates to his scheduler (H7, etc.) will be addressed as they are merged. Likewise, the 2.4 patch is for H7 only. Other versions are use-at-your-own-risk.
Any outstanding bugs please report. Comments, patches, etc. welcome.
Full ChangeLog:
- more preempt-safe work for new scheduling functions
- mark PREEMPT_ACTIVE jump in schedule unlikely
- optimize preempt_schedule
- change value of PREEMPT_ACTIVE (0x40000000=>0x400000)
- (2.5 only) report preempt_count in /proc/pid/stat
- more comments
Robert Love
A version of preempt-stats for the 2.5 series kernel is available at:
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-stats
and your favorite mirror. Patches for 2.4 are available, too.
This patch, used on top of preempt-kernel, allows the measuring of periods of non-preemptible so that we can identify long-held locks. The patch creates a proc entry, latencytimes, which contains the top 20 worst-case recorded periods since it was last read. To begin recording, read the file once. Subsequent reads will return the results. I.e.,
[23:25:08]rml@langston:~$ cat /proc/latencytimes
Worst 20 latency times of 277 measured in this period.
usec cause mask start line/file address end line/file
9982 spin_lock 0 488/sched.c c0117ee2 645/irq.c
968 BKL 0 666/tty_io.c c0193d58 645/irq.c
430 spin_lock 0 69/i387.c c010f34f 96/mmx.c
103 ide0 0 583/irq.c c010ab1c 645/irq.c
100 BKL 0 2562/buffer.c c014abda 2565/buffer.c
54 BKL 0 702/tty_io.c c019406b 704/tty_io.c
... etcThe goal would be to identity the problem areas and fix them.
Robert Love
Quoted 11 lines · Robert Love
A version of preempt-stats for the 2.5 series kernel is available at:
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-stats
and your favorite mirror. Patches for 2.4 are available, too.
This patch, used on top of preempt-kernel, allows the measuring of periods of non-preemptible so that we can identify long-held locks. The patch creates a proc entry, latencytimes, which contains the top 20 worst-case recorded periods since it was last read. To begin recording, read the file once. Subsequent reads will return the results. I.e.,
Nice, but you need a way to turn it off, for example:
echo >/proc/latencytimes
i.e., truncate.
Quoted 10 lines
[23:25:08]rml@langston:~$ cat /proc/latencytimes
Worst 20 latency times of 277 measured in this period.
usec cause mask start line/file address end line/file
9982 spin_lock 0 488/sched.c c0117ee2 645/irq.c
968 BKL 0 666/tty_io.c c0193d58 645/irq.c
430 spin_lock 0 69/i387.c c010f34f 96/mmx.c
103 ide0 0 583/irq.c c010ab1c 645/irq.c
100 BKL 0 2562/buffer.c c014abda 2565/buffer.c
54 BKL 0 702/tty_io.c c019406b 704/tty_io.c
... etcA more typical form for the file/line would be, e.g., irq.c:645
Quoted 1 line
The goal would be to identity the problem areas and fix them.
Yep, sorry about the nits but that's the way we nitbots are programmed.
--
Daniel
Quoted 11 lines · Robert Love
A version of preempt-stats for the 2.5 series kernel is available at:
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-stats
and your favorite mirror. Patches for 2.4 are available, too.
This patch, used on top of preempt-kernel, allows the measuring of periods of non-preemptible so that we can identify long-held locks. The patch creates a proc entry, latencytimes, which contains the top 20 worst-case recorded periods since it was last read. To begin recording, read the file once. Subsequent reads will return the results. I.e.,
Nice, but you need a way to turn it off, for example:
echo >/proc/latencytimes
i.e., truncate.
Quoted 10 lines
[23:25:08]rml@langston:~$ cat /proc/latencytimes
Worst 20 latency times of 277 measured in this period.
usec cause mask start line/file address end line/file
9982 spin_lock 0 488/sched.c c0117ee2 645/irq.c
968 BKL 0 666/tty_io.c c0193d58 645/irq.c
430 spin_lock 0 69/i387.c c010f34f 96/mmx.c
103 ide0 0 583/irq.c c010ab1c 645/irq.c
100 BKL 0 2562/buffer.c c014abda 2565/buffer.c
54 BKL 0 702/tty_io.c c019406b 704/tty_io.c
... etcA more typical form for the file/line would be, e.g., irq.c:645
Quoted 1 line
The goal would be to identity the problem areas and fix them.
Yep, sorry about the nits but that's the way we nitbots are programmed.
--
Daniel
Quoted 11 lines · Robert Love
A version of preempt-stats for the 2.5 series kernel is available at:
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-stats
and your favorite mirror. Patches for 2.4 are available, too.
This patch, used on top of preempt-kernel, allows the measuring of periods of non-preemptible so that we can identify long-held locks. The patch creates a proc entry, latencytimes, which contains the top 20 worst-case recorded periods since it was last read. To begin recording, read the file once. Subsequent reads will return the results. I.e.,
Nice, but you need a way to turn it off, for example:
echo >/proc/latencytimes
i.e., truncate.
Quoted 10 lines
[23:25:08]rml@langston:~$ cat /proc/latencytimes
Worst 20 latency times of 277 measured in this period.
usec cause mask start line/file address end line/file
9982 spin_lock 0 488/sched.c c0117ee2 645/irq.c
968 BKL 0 666/tty_io.c c0193d58 645/irq.c
430 spin_lock 0 69/i387.c c010f34f 96/mmx.c
103 ide0 0 583/irq.c c010ab1c 645/irq.c
100 BKL 0 2562/buffer.c c014abda 2565/buffer.c
54 BKL 0 702/tty_io.c c019406b 704/tty_io.c
... etcA more typical form for the file/line would be, e.g., irq.c:645
Quoted 1 line
The goal would be to identity the problem areas and fix them.
Yep, sorry about the nits but that's the way we nitbots are programmed.
--
Daniel