Skip to contentSkip to conversation

Updated Linux kernel preemption patches

DISCUSSION Robert Love 5 participants 14 messages Aug 27, 2001

lore
Share & tools
lore
#0 lore raw

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.

Signature · 3 lines
Robert M. Love
rml at ufl.edu
rml at tech9.net
#1 lore raw
Quoted 8 lines · Robert Love

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

#2 lore raw
Quoted 5 lines · Daniel Phillips

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.

Quoted 3 lines

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?

Signature · 3 lines
Robert M. Love
rml at ufl.edu
rml at tech9.net
#3 lore raw
In reply to Robert Love
Quoted 7 lines · 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.

Quoted 8 lines

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'

Signature · 2 lines
Cliff Albert		| RIPE:	     CA3348-RIPE | www.oisec.net
[email protected]		| 6BONE:     CA2-6BONE	 | icq 18461740
#4 lore raw
Quoted 1 line · Cliff Albert

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.

Signature · 3 lines
Robert M. Love
rml at ufl.edu
rml at tech9.net
#5 lore raw
In reply to Robert Love
Quoted 3 lines · Robert Love
Quoted 1 line

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

Signature · 2 lines
Cliff Albert		| RIPE:	     CA3348-RIPE | www.oisec.net
[email protected]		| 6BONE:     CA2-6BONE	 | icq 18461740
#6 lore raw
In reply to Robert Love

I get the same error -

RH 7.1 + updates and bits of rawhide -

Quoted 39 lines · Cliff Albert
Quoted 7 lines · 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.

Quoted 8 lines

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
[email protected]         | 6BONE:     CA2-6BONE   | icq 18461740

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#7 lore raw
Quoted 3 lines · J Sloan

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.

Signature · 3 lines
Robert M. Love
rml at ufl.edu
rml at tech9.net
#8 lore raw

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.

Signature · 3 lines
Robert M. Love
rml at ufl.edu
rml at tech9.net
#9 lore raw
In reply to Robert Love

Hello Robert Love,

Once you wrote about "Re: Updated Linux kernel preemption patches":

Quoted 11 lines · J Sloan
Quoted 3 lines

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.

Quoted 6 lines

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" ?

Signature · 2 lines
bye.
Andrey Nekrasov, SpyLOG.
#10 lore raw
Quoted 10 lines · Andrey Nekrasov

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.

Signature · 3 lines
Robert M. Love
rml at ufl.edu
rml at tech9.net
#11 lore raw
In reply to Robert Love
Quoted 6 lines · Robert Love

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

Quoted 5 lines

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

Quoted 1 line

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.

Signature · 2 lines
Cliff Albert		| RIPE:	     CA3348-RIPE | www.oisec.net
[email protected]		| 6BONE:     CA2-6BONE	 | icq 18461740
#12 lore raw
Quoted 2 lines · Cliff Albert

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

OK, so that is not the problem...

Quoted 2 lines

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?

Quoted 2 lines

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.

Signature · 3 lines
Robert M. Love
rml at ufl.edu
rml at tech9.net
#13 lore raw
In reply to Robert Love

Hello Robert Love,

Quoted 8 lines
Quoted 2 lines

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

Quoted 4 lines

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

Quoted 6 lines
Quoted 2 lines

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.

Signature · 2 lines
bye.
Andrey Nekrasov, SpyLOG.