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
On Mon, Mar 04, 2002 at 07:23:10PM -0500, Robert Love wrote:
> 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:
>
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
On Mon, 2002-03-04 at 19:41, Mike Fedyk wrote:
> > Users of 2.4+O(1)+preempt (i.e. -ac) should use this patch:
>
> 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...)
Uh, right. 2.4 users who use O(1) (which is in -ac) and preempt-kernel
need to use the aforementioned patch. :)
Robert Love
On Mon, Mar 04, 2002 at 07:23:10PM -0500, Robert Love wrote:
> 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
>
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'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.
I don't support pre-empt. If you can duplicate that without pre-empt then
its interesting, but not its not implausible
> 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.
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.
> Alan, do you want me to try without preempt, or do you already have any
> other reports like this?
No others, also knowing what it is actually running would be useful.
On Thu, Mar 07, 2002 at 11:46:17PM +0000, Alan Cox wrote:
> > 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.
>
> I don't support pre-empt. If you can duplicate that without pre-empt then
> its interesting, but not its not implausible
>
> > 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.
>
> 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.
>
> > Alan, do you want me to try without preempt, or do you already have any
> > other reports like this?
>
> 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
> 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.
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
On Fri, Mar 08, 2002 at 12:38:35AM +0000, Alan Cox wrote:
> > 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.
>
> 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?
> 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
On Fri, Mar 08, 2002 at 01:21:39PM +0000, Alan Cox wrote:
> > 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...
On Fri, Mar 08, 2002 at 11:26:43AM -0800, Mike Fedyk wrote:
> 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
> How could I test to kill everything opening glibc and still be able to run a
> command to read /proc/meminfo afterward?
Not easily. Can you give me a precise description of what is running and
I'll try and duplicate it