preempt-kernel on 2.4.19-pre2-ac2 bugfix

The same schedule_tail bug affecting 2.5 affects 2.4 with O(1). I.e., 2.4.19-pre2-ac2.

In recent O(1) scheduler releases, an optimization was made that removed schedule_tail from UP kernels. This causes the initial preempt_count of a new task, which starts at 1, to never decrement to zero and thus never become preemptible. CONFIG_PREEMPT requires schedule_tail, too.

Users of 2.4+O(1)+preempt (i.e. -ac) should use this patch:

	http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.19-pre2-ac2-2.patch

instead. Thanks to everyone who pointed out the lousy performance. Enjoy,

Robert Love

I believe you want to say that O(1)sched is in -ac, and this patch will add preempt on top of that, not that preempt is already in -ac (unless I missed something...)

Mike

Uh, right. 2.4 users who use O(1) (which is in -ac) and preempt-kernel need to use the aforementioned patch. :)

Robert Love

I'm using 2.4.19-pre2-ac2-prmpt which is only patched with:
preempt-kernel-rml-2.4.19-pre2-ac2-3

And it looks like the VM accounting has been messed up.

total: used: free: shared: buffers: cached:

Mem:  129662976 99065856 30597120        0  5013504 69664768
Swap: 500056064 97660928 402395136
MemTotal:       126624 kB
MemFree:         29880 kB
MemShared:           0 kB
Buffers:          4896 kB
Cached:          33188 kB
SwapCached:      34844 kB
Active:          62536 kB
Inact_dirty:     20328 kB
Inact_clean:       876 kB
Inact_target:    16748 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       126624 kB
LowFree:         29880 kB
SwapTotal:      488336 kB
SwapFree:       392964 kB
Committed AS:   366712 kB

As you can see, it says I'm using 366MB (roughly) of ram, but I'm only about 95mb into swap with 128mb of ram.

Alan, do you want me to try without preempt, or do you already have any other reports like this?

The kernel is compiled smp, but this machine is UP. I can post .config and other info if needed just ask.

Mike

I don't support pre-empt. If you can duplicate that without pre-empt then its interesting, but not its not implausible

That is the worst case swap usage based on the current allocations made by the system. My laptop for example isnt into swap at all but has a worst case of about 60Mb of swap.

No others, also knowing what it is actually running would be useful.

I'm running kde, mutt, mozilla, make -j5 kernel compile on a loop for the last coupld days. I wasn't using this much address space with the same work load yesterday, so that's why I think there is a bug there.

Although, I seem to recall running the same compile loop on a larger system (2x666 mhz p3 512mb ram, vnc, no local Xserver) on a previous (2.4.18-rc-ac) kernel without any other patches.

This machine is a 350 p2 with 128mb ram.

00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 02) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 02) 00:07.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02) 00:0d.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 08) 01:00.0 Display controller: Texas Instruments TVP4020 [Permedia 2] (rev 01)

Mike

Could be - or an app decided to spring a leak. You might want to see if a lot of it vanishes when you kill specific things

True.

Won't this show up in rss or some other ps mem listing -or- is this something that hasn't been exported to user space before on linux?

It might show up in /proc/<pid>/* - the maps list will show address spaces. Otherwise address space leaks have always been invisible and its only when you leak to 3Gb of unused address space the app will notice if its never touching it

I couldn't find any processes that looked to use a lot of address space, so I switched to single user mode (kills most everything...) and ran pstree and /proc/memstat:

init-+-bdflush

     |-init---bash---pstree
     |-keventd
     |-kjournald
     |-ksoftirqd_CPU0
     |-kswapd
     |-kupdated
     |-lockd
     |-mdrecoveryd
     `-rpciod
        total:    used:    free:  shared: buffers:  cached:
Mem:  129662976 110067712 19595264        0 11984896 78237696
Swap: 500056064    40960 500015104
MemTotal:       126624 kB
MemFree:         19136 kB
MemShared:           0 kB
Buffers:         11704 kB
Cached:          76364 kB
SwapCached:         40 kB
Active:          62440 kB
Inact_dirty:      9568 kB
Inact_clean:     16780 kB
Inact_target:    17756 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       126624 kB
LowFree:         19136 kB
SwapTotal:      488336 kB
SwapFree:       488296 kB
Committed AS:   355580 kB

I'll test without preempt and see if it shows up again. It took a day before though, so...

I've been running without preempt for about 28hrs with a make -j5 compile loop of a kernel tree running, and it looks like it'll do the same thing again.

Maybe it's from all of the forks as the only things that have been in use are:

mutt (left running, so scanning for new messages in several folders) exim (receiving message for lkml, debian-(devel|user), etc top
make -j loop

Mozilla is running, but I haven't been using it...

I'll change to single user mode in monday to check to see if the problem is reproducable on non-preempt.

The only thing left would be the kernel or glibc (as init still keeps it open so 'shutdown now' wouldn't free that).

How could I test to kill everything opening glibc and still be able to run a command to read /proc/meminfo afterward?

Mike

Not easily. Can you give me a precise description of what is running and I'll try and duplicate it