linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Ingo Molnar <mingo@elte.hu>,
	Roger Larsson <roger.larsson@norran.net>,
	MM mailing list <linux-mm@kvack.org>,
	linux-kernel@vger.kernel.org
Subject: Re: refill_inactive()
Date: Mon, 25 Sep 2000 09:17:54 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.10.10009250914100.1666-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0009251306430.14614-100000@duckman.distro.conectiva>


On Mon, 25 Sep 2000, Rik van Riel wrote:
> 
> Hmmm, doesn't GFP_BUFFER simply imply that we cannot
> allocate new buffer heads to do IO with??

No.

New buffer heads would be ok - recursion is fine in theory, as long as it
is bounded, and we might bound it some other way (I don't think we
_should_ do recursion here due to the stack limit, but at least it's not
a fundamental problem).

The fundamental problem is that GFP_BUFFER allocations are often done with
some critical filesystem lock held. Which means that we cannot call down
to the filesystem to free up memory.

The name is a misnomer, partly due to historical reasons (the buffer cache
used to be fragile, and if you free'd buffer cache pages while you were
trying to allocate new ones you could cause BadThings(tm) to happen), but
partly just because the only _user_ of it is the buffer cache. 

In theory, filesystems could use it for any other allocations that they
do, but in practice they don't, and the only allocations they do in
critical regions is the buffer allocation. And as this thread has
discussed, even that is really more of a bug than a feature.

		Linus

--
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/

  reply	other threads:[~2000-09-25 16:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-24  9:57 refill_inactive() Ingo Molnar
2000-09-24 10:15 ` refill_inactive() Arjan van de Ven
2000-09-24 10:56   ` refill_inactive() Ingo Molnar
2000-09-25 14:06 ` refill_inactive() Rik van Riel
2000-09-25 14:35   ` refill_inactive() Ingo Molnar
2000-09-25 16:08     ` refill_inactive() Rik van Riel
2000-09-25 16:17       ` Linus Torvalds [this message]
2000-09-25 16:33         ` refill_inactive() Rik van Riel
2000-09-25 17:45         ` refill_inactive() Stephen C. Tweedie

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.10.10009250914100.1666-100000@penguin.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=riel@conectiva.com.br \
    --cc=roger.larsson@norran.net \
    /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