linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zlatko Calusic <zlatko@iskon.hr>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: alan@redhat.com, linux-mm@kvack.org, linux-kernel@vger.rutgers.edu
Subject: Re: shrink_mmap() change in ac-21
Date: 20 Jun 2000 10:21:51 +0200	[thread overview]
Message-ID: <dnaeggn4o0.fsf@magla.iskon.hr> (raw)
In-Reply-To: "Manfred Spraul"'s message of "Mon, 19 Jun 2000 23:47:14 +0200"

"Manfred Spraul" <manfred@colorfullife.com> writes:

> From: "Zlatko Calusic" <zlatko@iskon.hr>
> >
> > The reason is balancing of the DMA zone (which is much smaller on a
> > 128MB machine than the NORMAL zone!). shrink_mmap() now happily evicts
> > wrong pages from the memory and continues doing so until it finally
> > frees enough pages from the DMA zone. That, of course, hurts caching
> > as the page cache gets shrunk a lot without a good reason.
> >
> What caused the zone balancing?
> Did you deliberately allocate GFP_DMA memory (sound card, old scsi card,
> floppy disk, ...) or was it during "normal" operation?
> 

No, I haven't done anything special with the DMA zone. But pages get
allocated from the DMA zone normally (it is almost 16MB of free RAM,
after all).

Then when kswapd kicks in because free memory in the DMA zone got low,
it starts freeing pages until we free enough pages from the DMA
zone. But it doesn't check if such a freeing hurts other zones.

Simple mathematics: On a 128MB machine, DMA zone is 16MB, thus NORMAL
zone is 112MB. 112/16 = 7. So statistically, for every DMA page freed,
we free another SEVEN! pages from the NORMAL zone. And we won't stop
doing such a genocide until DMA zone recovers.

That was 128MB machine, consider how the problem gets progressively
worse on machines with more RAM.
-- 
Zlatko
--
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-06-20  8:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-19 20:14 Zlatko Calusic
2000-06-19 21:07 ` Rik van Riel
2000-06-19 21:46 ` Jamie Lokier
2000-06-19 22:10   ` Rik van Riel
2000-06-19 22:43     ` Andrea Arcangeli
2000-06-19 22:48   ` Andrea Arcangeli
2000-06-20  9:03     ` Zlatko Calusic
2000-06-20 16:18     ` Rik van Riel
2000-06-20 16:53       ` Juan J. Quintela
2000-06-20 17:30         ` Manfred Spraul, Juan J. Quintela
2000-06-20 17:41           ` Juan J. Quintela
2000-06-20 19:00             ` Andrea Arcangeli
2000-06-19 21:47 ` Manfred Spraul, Zlatko Calusic
2000-06-20  8:21   ` Zlatko Calusic [this message]
2000-06-20 16:14     ` Manfred Spraul, Zlatko Calusic
2000-06-20 17:01       ` willy
2000-06-20 17:03         ` Alan Cox
     [not found] <200006202027.NAA01142@penguin.transmeta.com>
2000-06-20 22:59 ` Rik van Riel

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=dnaeggn4o0.fsf@magla.iskon.hr \
    --to=zlatko@iskon.hr \
    --cc=alan@redhat.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=manfred@colorfullife.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