Re: [PATCH] update: preemptive kernel for O(1) sched

Re: [PATCH] update: preemptive kernel for O(1) sched

[Robert Love]

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

Re: [PATCH] update: preemptive kernel for O(1) sched

[Dieter Nützel]

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

Re: [PATCH] update: preemptive kernel for O(1) sched

[William Lee Irwin III]

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

Re: [PATCH] update: preemptive kernel for O(1) sched

[Robert Love]

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

Re: [PATCH] update: preemptive kernel for O(1) sched

[Dieter Nützel]

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: Dieter.Nuetzel@hamburg.de

[PATCH] update: preemptive kernel for O(1) sched

[Robert Love]

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

Re: [PATCH] update: preemptive kernel for O(1) sched

[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
... etc

The goal would be to identity the problem areas and fix them.

	Robert Love

Re: [PATCH] update: preemptive kernel for O(1) sched

[Daniel Phillips]

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

Re: [PATCH] update: preemptive kernel for O(1) sched

[Daniel Phillips]

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

Re: [PATCH] update: preemptive kernel for O(1) sched

[Daniel Phillips]

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