Updated Linux kernel preemption patches

Updated Linux kernel preemption patches

[Robert Love]

Available at:

http://tech9.net/rml/linux/patch-rml-2.4.9-preempt-kernel-1
http://tech9.net/rml/linux/patch-rml-2.4.8-ac12-preempt-kernel-1

for kernel 2.4.9 and 2.4.8-ac12, respectively.

This is a straight update of Nigel Gamble's Linux kernel preemption
patch from http://kpreempt.sourceforge.net, updated for the above
kernels.  Thus, this is Nigel's code -- I merely updated it.

I am eager to see work done on the patch and to see what its future may
be.  If you are in any way interested in application latency or
real-time support, I suggest you check this out.  If you are just
curious, its an interesting patch none-the-less.

Some benchmarks:

kernel 2.4.8-ac12 (nonpreempt):
dbench 16:
Throughput 12.9453 MB/sec (NB=16.1816 MB/sec  129.453 MBit/sec)
dbench 1:
Throughput 76.0099 MB/sec (NB=95.0123 MB/sec  760.099 MBit/sec)
kernel compile (make dep clean bzImage):
7:35.51 (386.34s user, 23.41s system)

kernel 2.4.8-ac12 with preemptible kernel patch:
dbench 16:
Throughput 13.3579 MB/sec (NB=16.6974 MB/sec  133.579 MBit/sec)
dbench 1:
Throughput 31.4971 MB/sec (NB=39.3714 MB/sec  314.971 MBit/sec)
kernel compile (make dep clean bzImage):
7:23.26 (387.10s user, 23.42s system)

The performance increase in kernel compile and dbench 16 is decent, but
the decrease in dbench 1 is odd.  I am curious what numbers others find.
My "how does it feel" benchmark is that bandwidth seems similar while
multitasking may be a tad smoother with the patch.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Updated Linux kernel preemption patches

[Daniel Phillips]

On August 27, 2001 03:57 am, Robert Love wrote:
> This is a straight update of Nigel Gamble's Linux kernel preemption
> patch from http://kpreempt.sourceforge.net, updated for the above
> kernels.  Thus, this is Nigel's code -- I merely updated it.
> [...]
> The performance increase in kernel compile and dbench 16 is decent, but
> the decrease in dbench 1 is odd.  I am curious what numbers others find.
> My "how does it feel" benchmark is that bandwidth seems similar while
> multitasking may be a tad smoother with the patch.

Congratulations on showing evidence that preemption can improve performance 
under some loads, especially the all-important kernel compile.  Don't be too 
worried about the dbench 1 results, dbench can vary by a factor of 2 
depending on the alignment of the planets (ask Tridge).  Try something more 
stable like bonnie.

The theory goes that preemption improves performance by cutting down the time 
between IO completion and user task resume, with only a small cost in extra 
locking.  It would be nice to see profiling statistics to support this idea.

--
Daniel

Re: Updated Linux kernel preemption patches

[Robert Love]

On Sun, 2001-08-26 at 23:06, Daniel Phillips wrote:
> Congratulations on showing evidence that preemption can improve performance 
> under some loads, especially the all-important kernel compile.  Don't be too 
> worried about the dbench 1 results, dbench can vary by a factor of 2 
> depending on the alignment of the planets (ask Tridge).  Try something more 
> stable like bonnie.

I would be happy to run some other tests.  I was happy to see the kernel
compile prove faster, and I fully expected the dbench 16 results to show
an improvement.  But, while I assumed dbench 1 may show a degradation in
performance, I was surprised it was so high.

My main goal in updating Nigel's patches to recent kernels was to
accomplish just this: get some more data points, some more benchmarks,
and more eyes on the code and systems running the patch.

I am not an audio guy or otherwise in need of a lower-latency system,
but the possibility for an overall improvement in the kernel (even at
the expense of some cases) is worthwhile, to me.

> The theory goes that preemption improves performance by cutting down the time 
> between IO completion and user task resume, with only a small cost in extra 
> locking.  It would be nice to see profiling statistics to support this idea.

Anyone running the patch want to profile some situations and reach some
conclusions?

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Updated Linux kernel preemption patches

[Cliff Albert]

On Sun, Aug 26, 2001 at 09:57:43PM -0400, Robert Love wrote:

> Available at:
> 
> http://tech9.net/rml/linux/patch-rml-2.4.9-preempt-kernel-1
> http://tech9.net/rml/linux/patch-rml-2.4.8-ac12-preempt-kernel-1
> 
> for kernel 2.4.9 and 2.4.8-ac12, respectively.
> 
> This is a straight update of Nigel Gamble's Linux kernel preemption
> patch from http://kpreempt.sourceforge.net, updated for the above
> kernels.  Thus, this is Nigel's code -- I merely updated it.
> 
> I am eager to see work done on the patch and to see what its future may
> be.  If you are in any way interested in application latency or
> real-time support, I suggest you check this out.  If you are just
> curious, its an interesting patch none-the-less.

Kernel won't compile when this patch is applied to 2.4.8-ac12

kernel/kernel.o: In function `mmput':
kernel/kernel.o(.text+0x1853): undefined reference to `atomic_dec_and_lock'
kernel/kernel.o: In function `free_uid':
kernel/kernel.o(.text+0xaea0): undefined reference to `atomic_dec_and_lock'
fs/fs.o: In function `kill_super':
fs/fs.o(.text+0x7002): undefined reference to `atomic_dec_and_lock'
fs/fs.o: In function `dput':
fs/fs.o(.text+0x13365): undefined reference to `atomic_dec_and_lock'
fs/fs.o: In function `iput':
fs/fs.o(.text+0x15ed2): undefined reference to `atomic_dec_and_lock'


-- 
Cliff Albert		| RIPE:	     CA3348-RIPE | www.oisec.net
cliff@oisec.net		| 6BONE:     CA2-6BONE	 | icq 18461740

Re: Updated Linux kernel preemption patches

[Robert Love]

On Mon, 2001-08-27 at 03:38, Cliff Albert wrote:
> Kernel won't compile when this patch is applied to 2.4.8-ac12

is CONFIG_SMP set? the preempt patch and SMP are untested together.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Updated Linux kernel preemption patches

[Cliff Albert]

On Mon, Aug 27, 2001 at 09:46:12AM -0400, Robert Love wrote:

> > Kernel won't compile when this patch is applied to 2.4.8-ac12
> 
> is CONFIG_SMP set? the preempt patch and SMP are untested together.

Single CPU, no CONFIG_SMP set

-- 
Cliff Albert		| RIPE:	     CA3348-RIPE | www.oisec.net
cliff@oisec.net		| 6BONE:     CA2-6BONE	 | icq 18461740

Re: Updated Linux kernel preemption patches

[J Sloan]

I get the same error -

RH 7.1 + updates and bits of rawhide -


Cliff Albert wrote:

> On Sun, Aug 26, 2001 at 09:57:43PM -0400, Robert Love wrote:
>
> > Available at:
> >
> > http://tech9.net/rml/linux/patch-rml-2.4.9-preempt-kernel-1
> > http://tech9.net/rml/linux/patch-rml-2.4.8-ac12-preempt-kernel-1
> >
> > for kernel 2.4.9 and 2.4.8-ac12, respectively.
> >
> > This is a straight update of Nigel Gamble's Linux kernel preemption
> > patch from http://kpreempt.sourceforge.net, updated for the above
> > kernels.  Thus, this is Nigel's code -- I merely updated it.
> >
> > I am eager to see work done on the patch and to see what its future may
> > be.  If you are in any way interested in application latency or
> > real-time support, I suggest you check this out.  If you are just
> > curious, its an interesting patch none-the-less.
>
> Kernel won't compile when this patch is applied to 2.4.8-ac12
>
> kernel/kernel.o: In function `mmput':
> kernel/kernel.o(.text+0x1853): undefined reference to `atomic_dec_and_lock'
> kernel/kernel.o: In function `free_uid':
> kernel/kernel.o(.text+0xaea0): undefined reference to `atomic_dec_and_lock'
> fs/fs.o: In function `kill_super':
> fs/fs.o(.text+0x7002): undefined reference to `atomic_dec_and_lock'
> fs/fs.o: In function `dput':
> fs/fs.o(.text+0x13365): undefined reference to `atomic_dec_and_lock'
> fs/fs.o: In function `iput':
> fs/fs.o(.text+0x15ed2): undefined reference to `atomic_dec_and_lock'
>
> --
> Cliff Albert            | RIPE:      CA3348-RIPE | www.oisec.net
> cliff@oisec.net         | 6BONE:     CA2-6BONE   | icq 18461740
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Updated Linux kernel preemption patches

[Robert Love]

On Mon, 2001-08-27 at 15:31, J Sloan wrote:
> I get the same error -
> 
> RH 7.1 + updates and bits of rawhide -

I am looking into this, but I do not have this problem (which is odd).

The patch wraps one define of atomic_dec_and_lock in an #ifndef
CONFIG_PREEMPT, but I assume there is another defination elsewhere.  For
whatever reason, my kernel compiles fine.

I am going to update the patch to 2.4.9-ac2, give that a try.

Wait a second...you are _ENABLING_ the configure option, right?  Always
run `make oldconfig' !!!  If you are not, in this case, the patch is
breaking compiles where CONFIG_PREEMPT is not set...now I can fix that.
Please let me know.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Updated Linux kernel preemption patches

[Andrey Nekrasov]

Hello Robert Love,

Once you wrote about "Re: Updated Linux kernel preemption patches":
> On Mon, 2001-08-27 at 15:31, J Sloan wrote:
> > I get the same error -
> > 
> > RH 7.1 + updates and bits of rawhide -
> 
> I am looking into this, but I do not have this problem (which is odd).
> 
> The patch wraps one define of atomic_dec_and_lock in an #ifndef
> CONFIG_PREEMPT, but I assume there is another defination elsewhere.  For
> whatever reason, my kernel compiles fine.
> 
> I am going to update the patch to 2.4.9-ac2, give that a try.
> 
> Wait a second...you are _ENABLING_ the configure option, right?  Always
> run `make oldconfig' !!!  If you are not, in this case, the patch is
> breaking compiles where CONFIG_PREEMPT is not set...now I can fix that.
> Please let me know.

I am doing:

make clean
make menuconfig (load my config; enable/disable option if need)
make dep
make bzImage
(break with error)


Where should be "make oldconfig" ?

-- 
bye.
Andrey Nekrasov, SpyLOG.

Re: Updated Linux kernel preemption patches

[Robert Love]

On Mon, 2001-08-27 at 17:12, Andrey Nekrasov wrote:
> I am doing:
> 
> make clean
> make menuconfig (load my config; enable/disable option if need)
> make dep
> make bzImage
> (break with error)
> 
> 
> Where should be "make oldconfig" ?

You probably don't need to be doing oldconfig if you are doing
menuconfig and correctly filling everything out, although the correct
place to do it would be before menuconfig (let oldconfig prompt you on
new config options). thus,

`make oldconfig menuconfig dep clean bzImage'

is what you should do. if you are running `make dep', my theory is
wrong, and admittedly I don't know why it is not working for you.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Updated Linux kernel preemption patches

[Robert Love]

ahhh I think I got it. nevermind the bit about CONFIG_PREEMPT not being
set, that is not it (as I am sure you all know).

The problem is that dec_and_lock.c is not being compiled (or at least
the object isnt being included).  I believe this is caused by having bad
dependencies.  My .depend has a dependency to compile the object -- I
wager your's does not.

So... did you rerun `make dep' ?

If not, try a fresh kernel tree and make sure to do `make oldconfig dep
clean' after patching.

Please let me know because I am trying to track this down, and I don't
have it happening to me.  I think this should do it.

Of note, I will release a patch against 2.4.9-ac2 and 2.4.10-pre1 soon.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Updated Linux kernel preemption patches

[Cliff Albert]

On Mon, Aug 27, 2001 at 05:18:57PM -0400, Robert Love wrote:

> The problem is that dec_and_lock.c is not being compiled (or at least
> the object isnt being included).  I believe this is caused by having bad
> dependencies.  My .depend has a dependency to compile the object -- I
> wager your's does not.
> 
> So... did you rerun `make dep' ?

I ALWAYS run make dep && make clean && make bzImage when building a new 
kernel 

> If not, try a fresh kernel tree and make sure to do `make oldconfig dep
> clean' after patching.
> 
> Please let me know because I am trying to track this down, and I don't
> have it happening to me.  I think this should do it.

It still borks, probably you are having other options in your kernel config
and sections you don't use may depend on dec_and_lock

> Of note, I will release a patch against 2.4.9-ac2 and 2.4.10-pre1 soon.

First get it to work, and then spend time on keeping it current with alan's
and linus' tree.

-- 
Cliff Albert		| RIPE:	     CA3348-RIPE | www.oisec.net
cliff@oisec.net		| 6BONE:     CA2-6BONE	 | icq 18461740

Re: Updated Linux kernel preemption patches

[Robert Love]

On Mon, 2001-08-27 at 17:24, Cliff Albert wrote:
> I ALWAYS run make dep && make clean && make bzImage when building a new 
> kernel 

OK, so that is not the problem...

> It still borks, probably you are having other options in your kernel config
> and sections you don't use may depend on dec_and_lock

No, I have places in my kernel where atomic_dec_and_lock is used.  In
fact, one of the functions I was pasted where it broke was mmput() in
kernel.S (i think from fork.c).  I have that function, and it uses
atomic_dec_and_lock...

So the problem is most certainly something to do with your configuration
not getting the dependency right to use atomic_dec_and_lock

Out of curiosity, what CONFIG CPU are you defined to use? 
 
> First get it to work, and then spend time on keeping it current with alan's
> and linus' tree.

I am working, but it is not my code.  I am merely trying to keep it in
sync with the trees.  I am trying to get it working for those who it
does not compile for, but it works for me and others, so it is hard.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Updated Linux kernel preemption patches

[Andrey Nekrasov]

Hello Robert Love,

> > It still borks, probably you are having other options in your kernel config
> > and sections you don't use may depend on dec_and_lock
> 
> No, I have places in my kernel where atomic_dec_and_lock is used.  In
> fact, one of the functions I was pasted where it broke was mmput() in
> kernel.S (i think from fork.c).  I have that function, and it uses
> atomic_dec_and_lock...
> 
> So the problem is most certainly something to do with your configuration
> not getting the dependency right to use atomic_dec_and_lock
> 
> Out of curiosity, what CONFIG CPU are you defined to use? 

#
CONFIG_X86=y
...
CONFIG_MPENTIUMIII=y
...



> > First get it to work, and then spend time on keeping it current with alan's
> > and linus' tree.
> 
> I am working, but it is not my code.  I am merely trying to keep it in
> sync with the trees.  I am trying to get it working for those who it
> does not compile for, but it works for me and others, so it is hard.
 

-- 
bye.
Andrey Nekrasov, SpyLOG.