From: Andrea Arcangeli <andrea@suse.de>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: Linus Torvalds <torvalds@transmeta.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: pre6 VM issues
Date: Tue, 9 Oct 2001 16:50:02 +0200 [thread overview]
Message-ID: <20011009165002.H15943@athlon.random> (raw)
In-Reply-To: <Pine.LNX.4.21.0110091031470.5604-100000@freak.distro.conectiva>
In-Reply-To: <Pine.LNX.4.21.0110091031470.5604-100000@freak.distro.conectiva>; from marcelo@conectiva.com.br on Tue, Oct 09, 2001 at 10:44:37AM -0200
On Tue, Oct 09, 2001 at 10:44:37AM -0200, Marcelo Tosatti wrote:
>
> Hi,
>
> I've been testing pre6 (actually its pre5 a patch which Linus sent me
> named "prewith 16GB of RAM (thanks to OSDLabs for that), and I've found
> out some problems. First of all, we need to throttle normal allocators
> more often and/or update the low memory limits for normal allocators to a
> saner value. I already said I think allowing everybody to eat up to
> "freepages.min" is too low for a default.
>
> I've got atomic memory failures with _22GB_ of swap free (32GB total):
>
> eth0: can't fill rx buffer (force 0)!
>
> Another issue is the damn fork() special case. Its failing in practice:
>
> bash: fork: Cannot allocate memory
>
> Also with _LOTS_ of swap free. (gigs of them)
It could be just fragmentation but the fact it doesn't happen in
non-highmem pretty much shows that shows the memory balancing isn't
doing the right thing, you hide the problem with the infinite loop for
non atomic order 0 allocations and that's just broken, as best it will
be slower in collecting the right pages away.
My approch shouldn't fail so easily in fork despite I'm not looping in
fork either, because I'm trying to do better decisions since the first
place in the memory balancing, I don't wait the infinite loop to
eventually collect away the right pages.
Andrea
next prev parent reply other threads:[~2001-10-09 14:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-09 12:44 pre6 VM issues Marcelo Tosatti
2001-10-09 12:48 ` Marcelo Tosatti
2001-10-09 14:17 ` BALBIR SINGH
2001-10-09 13:01 ` Marcelo Tosatti
2001-10-09 14:37 ` BALBIR SINGH
2001-10-09 13:22 ` Marcelo Tosatti
2001-10-09 14:43 ` BALBIR SINGH
2001-10-09 14:44 ` Andrea Arcangeli
2001-10-09 14:56 ` BALBIR SINGH
2001-10-09 14:31 ` Andrea Arcangeli
2001-10-09 13:13 ` Marcelo Tosatti
2001-10-09 14:42 ` Andrea Arcangeli
2001-10-09 13:23 ` Marcelo Tosatti
2001-10-09 14:53 ` Andrea Arcangeli
2001-10-09 14:50 ` Andrea Arcangeli [this message]
2001-10-09 13:34 ` Marcelo Tosatti
2001-10-09 15:39 ` Andrea Arcangeli
2001-10-09 15:08 ` Marcelo Tosatti
2001-10-09 16:49 ` Andrea Arcangeli
2001-10-09 17:07 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011009165002.H15943@athlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox