linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Cc: Bill Hawes <whawes@star.net>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	Alan Cox <number6@the-village.bc.nu>,
	"David S. Miller" <davem@dm.cobaltmicro.com>,
	Ingo Molnar <mingo@valerie.inf.elte.hu>,
	Mark Hemment <markhe@nextd.demon.co.uk>,
	linux-mm@kvack.org, linux-kernel@vger.rutgers.edu
Subject: Re: Good and bad news on 2.1.110, and a fix
Date: Mon, 27 Jul 1998 12:07:27 +0100	[thread overview]
Message-ID: <199807271107.MAA00717@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.96.980723222349.18464C-100000@mirkwood.dummy.home>

Hi,

On Thu, 23 Jul 1998 22:28:39 +0200 (CEST), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

> On Thu, 23 Jul 1998, Bill Hawes wrote:
>> Stephen C. Tweedie wrote:
>> 
>> > The patch to page_alloc.c is a minimal fix for the fragmentation
>> > problem.  It simply records allocation failures for high-order pages,
>> > and forces free_memory_available to return false until a page of at
>> > least that order becomes available.  The impact should be low, since

> This sound suspiciously like the first version of
> free_memory_available() that Linus introduced in
> 2.1.89...

No, it's very different; first, it is adaptive, and second, it only
waits for _one_ of the higher order free page lists to be filled.  The
patch carefully does absolutely nothing until we get a definite
failure to get a higher order page, and then it does the minimum
necessary work to satisfy one request before going inactive again. 

It is the minimum necessary patch to keep the kernel from locking up,
but it does nothing at all most of the time.  

> It will happen for sure; just think of what will happen
> when that 64 kB DMA allocation fails on your 6 MB box :(

Which is one reason why we probably want to timeout the condition
after a second or two.

> Maybe we want to count the number of order-3 memory structures
> free and keep that number above a certain level (back to
> Zlatko's 2.1.59 patch :-).

Again, it's arbitrary, and would result in unnecessary extra
activity.  What we'd like to do is make sure we only do _necessary_
pageing work, and keep as much memory as possible in use the rest of
the time.

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

      reply	other threads:[~1998-07-27 19:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-23 12:48 Stephen C. Tweedie
1998-07-23 16:08 ` Bill Hawes
1998-07-23 17:30   ` Stephen C. Tweedie
1998-07-23 20:28   ` Rik van Riel
1998-07-27 11:07     ` Stephen C. Tweedie [this message]

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=199807271107.MAA00717@dax.dcs.ed.ac.uk \
    --to=sct@redhat.com \
    --cc=H.H.vanRiel@phys.uu.nl \
    --cc=davem@dm.cobaltmicro.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=markhe@nextd.demon.co.uk \
    --cc=mingo@valerie.inf.elte.hu \
    --cc=number6@the-village.bc.nu \
    --cc=torvalds@transmeta.com \
    --cc=whawes@star.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