From: Rik van Riel <riel@conectiva.com.br>
To: Mike Galbraith <mikeg@wen-online.de>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
Date: Thu, 24 May 2001 08:03:49 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.4.33.0105240800020.10469-100000@duckman.distro.conectiva> (raw)
In-Reply-To: <Pine.LNX.4.33.0105241123510.489-100000@mikeg.weiden.de>
On Thu, 24 May 2001, Mike Galbraith wrote:
> On Thu, 24 May 2001, Rik van Riel wrote:
> > On Thu, 24 May 2001, Mike Galbraith wrote:
> > > On Sun, 20 May 2001, Rik van Riel wrote:
> > >
> > > > Remember that inactive_clean pages are always immediately
> > > > reclaimable by __alloc_pages(), if you measured a performance
> > > > difference by freeing pages in a different way I'm pretty sure
> > > > it's a side effect of something else. What that something
> > > > else is I'm curious to find out, but I'm pretty convinced that
> > > > throwing away data early isn't the way to go.
> > >
> > > OK.. let's forget about throughput for a moment and consider
> > > those annoying reports of 0 order allocations failing :)
> >
> > Those are ok. All failing 0 order allocations are either
> > atomic allocations or GFP_BUFFER allocations. I guess we
> > should just remove the printk() ;)
>
> Hmm. The guy who's box locks up on him after a burst of these
> probably doesn't think these failures are very OK ;-) I don't
> think order 0 failing is cool at all.. ever.
You may not think it's cool, but it's needed in order to
prevent deadlocks. Just because an allocation cannot do
disk IO or sleep, that's no reason to loop around like
crazy in __alloc_pages() and hang the machine ... ;)
> A (long) while back, Linus specifically mentioned worrying
> about atomic allocation reliability.
That's a separate issue. That was, IIRC, about the
failure of atomic allocations causing packet loss on
Linux routers and, because of that, poor performance.
This is something we still need to look into, but
basically this problem is about too high latency and
NOT about "pre-freeing" more pages (like your patch
attempts). If this problem is still an issue, it's
quite likely that the VM is holding locks for too
long so that it cannot react fast enough to free up
some inactive_clean pages.
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-05-24 11:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.21.0105181403280.5531-100000@imladris.rielhome.conectiva>
[not found] ` <Pine.LNX.4.33.0105181936240.583-100000@mikeg.weiden.de>
2001-05-18 18:19 ` Ingo Oeser
2001-05-18 18:23 ` Rik van Riel
2001-05-18 18:58 ` Ingo Oeser
2001-05-18 20:12 ` Rik van Riel
2001-05-18 20:24 ` Mike Galbraith
2001-05-18 20:09 ` Mike Galbraith
2001-05-18 22:44 ` Rik van Riel
2001-05-18 22:58 ` Stephen C. Tweedie
2001-05-19 2:12 ` Rik van Riel
2001-05-19 2:32 ` Mike Castle
2001-05-19 6:45 ` Mike Galbraith
2001-05-19 4:40 ` Mike Galbraith
2001-05-19 17:13 ` [RFC][PATCH] " Mike Galbraith
2001-05-19 21:41 ` Rik van Riel
2001-05-20 3:29 ` Mike Galbraith
2001-05-20 6:42 ` Rik van Riel
2001-05-20 8:08 ` Mike Galbraith
[not found] ` <Pine.LNX.4.21.0105200546241.5531-100000@imladris.rielhome.conectiva>
2001-05-20 9:47 ` Mike Galbraith
[not found] ` <Pine.LNX.4.21.0105200703270.5531-100000@imladris.rielhome.conectiva>
2001-05-21 13:36 ` Stephen C. Tweedie
2001-05-20 21:54 ` Pavel Machek
2001-05-21 20:32 ` David Weinehall
2001-05-23 15:34 ` Rik van Riel
2001-05-23 17:24 ` Jonathan Morton
2001-05-25 8:39 ` Pavel Machek
2001-05-23 17:51 ` Scott Anderson
2001-05-25 8:10 ` David Weinehall
2001-05-25 18:39 ` Pavel Machek
2001-06-04 19:22 ` RPM Installation - Compilation errors jalaja devi
2001-05-24 8:48 ` [RFC][PATCH] Re: Linux 2.4.4-ac10 Mike Galbraith
2001-05-24 9:10 ` Rik van Riel
2001-05-24 10:32 ` Mike Galbraith
2001-05-24 11:03 ` Rik van Riel [this message]
2001-05-24 14:23 ` Mike Galbraith
2001-05-20 15:32 ` Ingo Oeser
2001-05-20 17:38 ` Mike Galbraith
2001-05-20 13:44 ` Zlatko Calusic
2001-05-20 17:58 ` Mike Galbraith
2001-05-20 19:32 ` Marcelo Tosatti
2001-05-20 21:03 ` Marcelo Tosatti
2001-05-21 3:54 ` Mike Galbraith
[not found] <Pine.LNX.4.21.0105201837240.5531-100000@imladris.rielhome.conectiva>
2001-05-21 3:44 ` Mike Galbraith
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=Pine.LNX.4.33.0105240800020.10469-100000@duckman.distro.conectiva \
--to=riel@conectiva.com.br \
--cc=ingo.oeser@informatik.tu-chemnitz.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mikeg@wen-online.de \
--cc=sct@redhat.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