linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Benjamin C.R. LaHaise" <blah@kvack.org>
To: Kanoj Sarcar <kanoj@google.engr.sgi.com>
Cc: Andrea Arcangeli <andrea@suse.de>,
	Rik van Riel <riel@nl.linux.org>,
	torvalds@transmeta.com, mingo@chiara.csoma.elte.hu,
	alan@lxorguk.ukuu.org.uk, linux-mm@kvack.org,
	linux-kernel@vger.rutgers.edu
Subject: Re: [RFC] 2.3.39 zone balancing
Date: Thu, 13 Jan 2000 16:34:15 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.3.96.1000113161742.1295B-100000@kanga.kvack.org> (raw)
In-Reply-To: <200001132102.NAA20091@google.engr.sgi.com>

On Thu, 13 Jan 2000, Kanoj Sarcar wrote:

> No, I am referring to a different problem that I mentioned in the
> doc. If you have a large number of free regular pages, and the dma
> zone is completely exhausted, the 2.2 decision of balacing the dma
> zone might never fetch an "yes" answer, because it is based on total
> number of free pages, not also the per zone free pages. Right? Things 
> will get worse the more non-dma pages there are.

Kanoj, you're wrong.  2.2 works quite well because of the fact that the
low memory mark will tend to consist almost entirely of DMAable pages.
The only allocations that regularly eat into them on a loaded machine are
interrupts, which tend to be short term allocations anyways.  But as soon
as DMAable memory is freed, it tends not to be allocated until interrupts
consume all memory again.

> Oh, okay I see. There is nothing about the dma zone then, you could 
> make the balancing more aggressive for the other zones too. Basically,
> these kinds of tuning should be controlled by sysctls (instead of 
> >>7, do >> N), so while most sites will prefer to run with the least
> aggressive balancing, there may be sites with drivers that need 
> many high-order pages, they would be willing to sacrifice some 
> performance by doing more aggressive balancing. Comes under finetuning 
> in the doc.

Whoa, hold on here.  Last time we tried to do more aggresive balancing, it
was a complete and total disaster that resulted in completely random swap
storms, resulting in spectacularly unusable systems on the lower end
(iirc 64mb was around the breakeven point).  Before harder limits are
placed on memory types and orders, the behaviour of both kswapd and the
allocator need to be tweaked.  so put in the mechanism, but don't start
enforcing it too aggresively.

		-ben

--
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.nl.linux.org/Linux-MM/

  reply	other threads:[~2000-01-13 21:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-12 21:11 Kanoj Sarcar
2000-01-13 13:40 ` Rik van Riel
2000-01-13 17:06   ` Andrea Arcangeli
2000-01-13 17:18   ` Alan Cox
2000-01-13 18:37     ` Rik van Riel
2000-01-13 20:13       ` Andrea Arcangeli
2000-01-13 21:12         ` Rik van Riel
2000-01-13 21:40         ` Kanoj Sarcar
2000-01-14 12:25           ` Jamie Lokier
2000-01-14 13:43             ` Andrea Arcangeli
2000-01-13 18:52   ` Kanoj Sarcar
2000-01-13 19:59     ` Andrea Arcangeli
2000-01-13 21:02       ` Kanoj Sarcar
2000-01-13 21:34         ` Benjamin C.R. LaHaise [this message]
2000-01-13 21:48           ` Kanoj Sarcar
2000-01-13 21:42         ` Alan Cox
2000-01-13 21:50           ` Kanoj Sarcar
2000-01-13 21:53             ` Alan Cox
2000-01-13 22:01           ` Linus Torvalds
2000-01-13 22:13             ` Kanoj Sarcar
2000-01-13 22:28               ` Rik van Riel
2000-01-13 22:30               ` Linus Torvalds
2000-01-13 23:53                 ` Ingo Molnar
2000-01-13 23:29                   ` Linus Torvalds
2000-01-14  0:33                     ` Andrea Arcangeli
2000-01-14  0:52                       ` Linus Torvalds
2000-01-14  1:08                         ` Rik van Riel
2000-01-14  2:13                         ` Ingo Molnar
2000-01-14  1:17                           ` Kanoj Sarcar
2000-01-14  2:36                             ` Ingo Molnar
2000-01-14 20:33                               ` Peter Rival
2000-01-14  1:13                       ` Kanoj Sarcar
2000-01-14  2:27                         ` Ingo Molnar
2000-01-14  2:46                         ` Ingo Molnar
2000-01-14  6:22                           ` Kanoj Sarcar
2000-01-15  2:03                     ` Reworked 2.3.39 zone balancing - v1 Kanoj Sarcar
2000-01-14  0:28                 ` [RFC] 2.3.39 zone balancing Andrea Arcangeli
2000-01-13 17:12 ` Andrea Arcangeli
2000-01-13 18:30   ` Kanoj Sarcar
2000-01-13 19:22     ` Andrea Arcangeli

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.3.96.1000113161742.1295B-100000@kanga.kvack.org \
    --to=blah@kvack.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andrea@suse.de \
    --cc=kanoj@google.engr.sgi.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=mingo@chiara.csoma.elte.hu \
    --cc=riel@nl.linux.org \
    --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