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
Robert,
what about lock-break?
I am running your former one as always with
lock-break-rml-2.4.18-pre1-1.patch ...;-)
Any success together with AA vm-22?
What about latencytest0.42-png for latency testing?
Regards,
Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Sun, 2002-01-13 at 18:22, Dieter N?tzel wrote:
> what about lock-break?
> I am running your former one as always with
> lock-break-rml-2.4.18-pre1-1.patch ...;-)
I haven't tested O(1) together with lock-break personally, yet, but I
have a confirmation of success from a couple of users. There are no
reasons it shouldn't work.
> Any success together with AA vm-22?
Again I don't have any personal tests. I do know, however, the Rik's
rmap VM works great.
I suspect Andrea's updated VM from -aa will work, but there may be other
parts of his patch (RCU) that are not preempt friendly.
> What about latencytest0.42-png for latency testing?
A good test.
Robert Love
On Monday, 14. January 2002 00:48, you wrote:
> On Sun, 2002-01-13 at 18:22, Dieter N?tzel wrote:
> > what about lock-break?
> > I am running your former one as always with
> > lock-break-rml-2.4.18-pre1-1.patch ...;-)
>
> I haven't tested O(1) together with lock-break personally, yet, but I
> have a confirmation of success from a couple of users. There are no
> reasons it shouldn't work.
I'll say that I am running this altogether.
Only vm-22 or rmap-11 are missing for now.
2.4.17 was running for me with vm-21 and preempt+look-beak.
> > Any success together with AA vm-22?
>
> Again I don't have any personal tests. I do know, however, the Rik's
> rmap VM works great.
AA, too . Best throughput I've ever seen.
> I suspect Andrea's updated VM from -aa will work, but there may be other
> parts of his patch (RCU) that are not preempt friendly.
But I've only used the VM parts not RCU, etc.
> > What about latencytest0.42-png for latency testing?
>
> A good test.
Expect some numbers (latency) for O(1) with and without preempt+lock-break
maybe with AA-VM, soon.
-Dieter
On Sun, 2002-01-13 at 18:22, Dieter N?tzel wrote:
>> what about lock-break?
>> I am running your former one as always with
>> lock-break-rml-2.4.18-pre1-1.patch ...;-)
On Sun, Jan 13, 2002 at 06:48:17PM -0500, Robert Love wrote:
> I haven't tested O(1) together with lock-break personally, yet, but I
> have a confirmation of success from a couple of users. There are no
> reasons it shouldn't work.
I have at least run it on my laptop, together with rmap even.
No pathological behavior that I can tell. Of course, the interactive
response is wonderful, but I haven't precisely measured anything, as
I have enough other things to measure precisely it's a bit far afield.
Cheers,
Bill
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
... etc
The goal would be to identity the problem areas and fix them.
Robert Love
On January 14, 2002 05:34 am, Robert Love wrote:
> 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.
> [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
> ... etc
A more typical form for the file/line would be, e.g., irq.c:645
> 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
preempt-kernel for 2.5.2:
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.5
Note, again, this patch is not compatible with later O(1) patches due to
the load_balance changes. I'll make the changes as they are merged into
2.5 proper.
No other changes in this release.
Robert Love
On January 14, 2002 05:34 am, Robert Love wrote:
> 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.
> [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
> ... etc
A more typical form for the file/line would be, e.g., irq.c:645
> 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
On January 14, 2002 05:34 am, Robert Love wrote:
> 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.
> [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
> ... etc
A more typical form for the file/line would be, e.g., irq.c:645
> 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