Just patched 2.4.18 first into 2.4.19-pre3 and direct into 2.4.19-pre3-ac1.
Couldn't get compile through because of error /linux/drivers/md/md.c.
Looked and found patch for 2.5.6 series kernel and used it...Now compile
succeeded.
I'm not sure if bug is in pre3 or pre3-ac1,but I'm sure it's not in 2.4.18,I
got that compiled without any errors.
So just wanted to notify...
Jarmo
> Just patched 2.4.18 first into 2.4.19-pre3 and direct into 2.4.19-pre3-ac1.
> Couldn't get compile through because of error /linux/drivers/md/md.c.
md definitely builds. You might want to check for merge errors, or provide
the actual error to the list ?
> - 2.4.19-pre-ac: kswapd try to swap out and access disk continuously. Whole
> system is slow down and un-interactivable.
echo "2" >/proc/sys/vm/overcommit_memory
On Mon, Mar 18, 2002 at 11:44:27AM +0000, Alan Cox wrote:
> > - 2.4.19-pre-ac: kswapd try to swap out and access disk continuously. Whole
> > system is slow down and un-interactivable.
>
> echo "2" >/proc/sys/vm/overcommit_memory
Why are you using the value "2"?
It makes me think that it activates some special magic,
but all I can find in mmap.c is:
/* Sometimes we want to use more memory than we have. */
if (sysctl_overcommit_memory)
return 1;
Regards,
Toon.
--
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
On Monday 18 March 2002 06:44 pm, Alan Cox wrote:
> > - 2.4.19-pre-ac: kswapd try to swap out and access disk continuously.
> > Whole system is slow down and un-interactivable.
>
> echo "2" >/proc/sys/vm/overcommit_memory
Couldn't load JBuilder (Out of memomy).
echo "1" >/proc/sys/vm/overcommit_memory => solved my 1st problem. I can
build and run my project from inside JBuilder. But OOM killer still doesn't
work (2nd). Anyway, thank you. I will play with your Magic numbers later,
Wizard ;). There are still alot of things to play with.
On Monday 18 March 2002 10:03 am, Rik van Riel wrote:
> On Sun, 17 Mar 2002, Mike Fedyk wrote:
> > Can you reproduce with just rmap12h from http://www.surriel.com/patches/
> > on top of 2.4.18?
>
> He probably can.
Compiled, but not test it yet. I will do it tonight. Thanks alot Rik, Mike,
Alan...
Best regards,
MrChuoi
> On Monday 18 March 2002 06:44 pm, Alan Cox wrote:
> > > - 2.4.19-pre-ac: kswapd try to swap out and access disk continuously.
> > > Whole system is slow down and un-interactivable.
> >
> > echo "2" >/proc/sys/vm/overcommit_memory
> Couldn't load JBuilder (Out of memomy).
Good. Thats working - it stopped you even potentially getting out of memory
which is what that overcommit mode is supposed to do. Basically it'll stop
you before you risk OOM cases
> build and run my project from inside JBuilder. But OOM killer still doesn't
> work (2nd). Anyway, thank you. I will play with your Magic numbers later,
> Wizard ;). There are still alot of things to play with.
Rik is the wizard for the rmap oom. He posted a test patch to fix some OOM
logic. I'm just doing the code so you can decide OOM is not permitted to
occur 8)
Hi,
Just a question, does the commited as field specify how much memory has
actually been *allocated* as per requests, but not necesserily in use?
This one is my home box, looks a bit crazy don't you think? The box has
about ~120 processes right now, heavy X session (2000x2000@32 virtual,
KDE2 with lots of eye candy), two kernel builds in the background and
cdrecord.
Linux version 2.4.19-pre2-ac3 (zwane@montezuma) (gcc version 2.96 20000731
(Red Hat Linux 7.1 2.96-98)) #2 Sat Mar 9 20:44:38 SAST 2002
total: used: free: shared: buffers: cached:
Mem: 527527936 519610368 7917568 0 16871424 398352384
Swap: 542785536 73433088 469352448
MemTotal: 515164 kB
MemFree: 7732 kB
MemShared: 0 kB
Buffers: 16476 kB
Cached: 380044 kB
SwapCached: 8972 kB
Active: 262252 kB
Inact_dirty: 209392 kB
Inact_clean: 11248 kB
Inact_target: 96576 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 515164 kB
LowFree: 7732 kB
SwapTotal: 530064 kB
SwapFree: 458352 kB
Committed AS: 8060848 kB
Things could get interesting if everyone touches their pages ;)
On Tue, Mar 19, 2002 at 07:54:12AM +0200, Zwane Mwaikambo wrote:
> Hi,
> Just a question, does the commited as field specify how much memory has
> actually been *allocated* as per requests, but not necesserily in use?
> This one is my home box, looks a bit crazy don't you think? The box has
> about ~120 processes right now, heavy X session (2000x2000@32 virtual,
> KDE2 with lots of eye candy), two kernel builds in the background and
> cdrecord.
>
> Linux version 2.4.19-pre2-ac3 (zwane@montezuma) (gcc version 2.96 20000731
> (Red Hat Linux 7.1 2.96-98)) #2 Sat Mar 9 20:44:38 SAST 2002
>
> total: used: free: shared: buffers: cached:
> Mem: 527527936 519610368 7917568 0 16871424 398352384
> Swap: 542785536 73433088 469352448
> MemTotal: 515164 kB
> MemFree: 7732 kB
> MemShared: 0 kB
> Buffers: 16476 kB
> Cached: 380044 kB
> SwapCached: 8972 kB
> Active: 262252 kB
> Inact_dirty: 209392 kB
> Inact_clean: 11248 kB
> Inact_target: 96576 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 515164 kB
> LowFree: 7732 kB
> SwapTotal: 530064 kB
> SwapFree: 458352 kB
> Committed AS: 8060848 kB
>
> Things could get interesting if everyone touches their pages ;)
What's your uptime?
I've been able to get "Committed AS" to just grow and grow with a kernel
compile within a while loop after a couple days (pii 350, so faster machines
should show that sooner...).
When you get a chance, go into single user mode and see if "Committed AS"
goes down to a sane level. If not, you're seeing what I am.
I've seen it without highmem, with and without smp, etc. more info available
upon request.
Mike
On Mon, 18 Mar 2002, Mike Fedyk wrote:
> What's your uptime?
Almost a day
> I've been able to get "Committed AS" to just grow and grow with a kernel
> compile within a while loop after a couple days (pii 350, so faster machines
> should show that sooner...).
Hmm i can check after about 2 days, i usually thrash the box really hard
so that might increase if i spend a bit more time on it.
> When you get a chance, go into single user mode and see if "Committed AS"
> goes down to a sane level. If not, you're seeing what I am.
I'll try that out.
Cheers,
Zwane
> actually been *allocated* as per requests, but not necesserily in use?
> This one is my home box, looks a bit crazy don't you think? The box has
Yes
> about ~120 processes right now, heavy X session (2000x2000@32 virtual,
> KDE2 with lots of eye candy), two kernel builds in the background and
> cdrecord.
I'm chasing a leak or two somewhere. One common theme seems to be KDE so
my guess is there is something like an mprotect/mremap/shared page path that
isnt correctly accounted and kde triggers more than most other stuff (eg
because of the strange way KDE execs new processes).
Last night I added some validator code for the non shmfs cases to see if
I can find it.
On Tue, Mar 19, 2002 at 01:32:13PM +0000, Alan Cox wrote:
> > actually been *allocated* as per requests, but not necesserily in use?
> > This one is my home box, looks a bit crazy don't you think? The box has
>
> Yes
>
> > about ~120 processes right now, heavy X session (2000x2000@32 virtual,
> > KDE2 with lots of eye candy), two kernel builds in the background and
> > cdrecord.
>
> I'm chasing a leak or two somewhere. One common theme seems to be KDE so
> my guess is there is something like an mprotect/mremap/shared page path that
> isnt correctly accounted and kde triggers more than most other stuff (eg
> because of the strange way KDE execs new processes).
>
> Last night I added some validator code for the non shmfs cases to see if
> I can find it.
Hmm, you must have missed my report I sent to you earlier.
After a fresh reboot, I booted into the console (no X/kde started) and ran the
while looped kernel compile for a couple days. Then I switched to single
user mode to see if the address space was recovered, but it was not.
Is there any way (I don't thing so, but...) that KDE can affect this when
there aren't any KDE processes running?
Mike
> Is there any way (I don't thing so, but...) that KDE can affect this when
> there aren't any KDE processes running?
Please try -ac2. It seems KDE just happens to be one of the triggers for
a bug where someone mremaps a partial vma larger and moves it.
On Tue, Mar 19, 2002 at 06:26:09PM +0000, Alan Cox wrote:
> > Is there any way (I don't thing so, but...) that KDE can affect this when
> > there aren't any KDE processes running?
>
> Please try -ac2. It seems KDE just happens to be one of the triggers for
> a bug where someone mremaps a partial vma larger and moves it.
OK, will do.
I didn't get down to that thread yet when I posted...
Mike
On Tue, Mar 19, 2002 at 10:29:33AM -0800, Mike Fedyk wrote:
> On Tue, Mar 19, 2002 at 06:26:09PM +0000, Alan Cox wrote:
> > > Is there any way (I don't thing so, but...) that KDE can affect this when
> > > there aren't any KDE processes running?
> >
> > Please try -ac2. It seems KDE just happens to be one of the triggers for
> > a bug where someone mremaps a partial vma larger and moves it.
>
> OK, will do.
>
Ok, did.
So far, after "up 1 day, 2:14" running a "while; make -j5" loop I haven't
seen my Committed_AS grow like before.
In multi user mode 116 processes running (with make -j loop):
total: used: free: shared: buffers: cached:
Mem: 129703936 117108736 12595200 0 3862528 58535936
Swap: 500056064 70832128 429223936
MemTotal: 126664 kB
MemFree: 12300 kB
MemShared: 0 kB
Buffers: 3772 kB
Cached: 24416 kB
SwapCached: 32748 kB
Active: 78996 kB
Inact_dirty: 18796 kB
Inact_clean: 1912 kB
Inact_target: 19940 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 126664 kB
LowFree: 12300 kB
SwapTotal: 488336 kB
SwapFree: 419164 kB
Committed_AS: 133840 kB
After:
total: used: free: shared: buffers: cached:
Mem: 129703936 76472320 53231616 0 8724480 54001664
Swap: 500056064 40960 500015104
MemTotal: 126664 kB
MemFree: 51984 kB
MemShared: 0 kB
Buffers: 8520 kB
Cached: 52696 kB
SwapCached: 40 kB
Active: 40848 kB
Inact_dirty: 16264 kB
Inact_clean: 5852 kB
Inact_target: 12592 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 126664 kB
LowFree: 51984 kB
SwapTotal: 488336 kB
SwapFree: 488296 kB
Committed_AS: 2228 kB
^^^^
This was down to ~500k before mutt was started.
init-+-bdflush
|-init---bash---bash-+-mutt---editor
| `-pstree
|-keventd
|-kjournald
|-ksoftirqd_CPU0
|-kswapd
|-kupdated
|-lockd
|-mdrecoveryd
`-rpciod
> Committed_AS: 2228 kB
> ^^^^
> This was down to ~500k before mutt was started.
That looks much better. If you want to do an absolute sanity test build a
non SMP kernel without SYSVIPC support, but with the accounting validation
turned on (mm/memory.c I believe I stuck it in) and it'll burp in the log
whenever it finds an error in the tally