From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Ben LaHaise <bcrl@redhat.com>,
linux-mm@kvack.org, torvalds@transmeta.com
Subject: Re: [patch] first bit of vm balancing fixes for 2.3.52-1
Date: Mon, 20 Mar 2000 12:58:23 -0800 (PST) [thread overview]
Message-ID: <200003202058.MAA47885@google.engr.sgi.com> (raw)
In-Reply-To: <14546.9883.575748.695740@dukat.scot.redhat.com> from "Stephen C. Tweedie" at Mar 17, 2000 12:35:39 PM
>
> Hi,
>
> On Mon, 13 Mar 2000 17:50:50 -0500 (EST), Ben LaHaise <bcrl@redhat.com>
> said:
>
> > This is the first little bit of a few vm balancing patches I've been
> > working on.
>
> Just out of interest, is anyone working on fixing the zone balancing?
>
> The current behaviour is highly suboptimal: if you have two zones to
> pick from for a given alloc_page(), and the first zone is at its
> pages_min threshold, then we will always allocate from that first zone
> and push it into kswap activation no matter how much free space there is
> in the next zone.
Hmm, I disagree for 2.3.50 and pre1 ... note that the decision of
low-memoryness is taken based on _cumulative_ free and number of pages,
so whether you allocate from the regular or dma zone, you should be
stealing and poking kswapd roughly the same number of times. As far as
I can see, spreading the allocation over lower class zones does not seem
to have advantages in this case.
With Linus' change to the page alloc code in pre2, yes, spreading
the allocation is an option, but I would be real careful before
putting that in 2.4.
Kanoj
>
> The net effect of this is that we may not _ever_ end up using the next
> zone for allocations if the request trickle in slowly enough; and that
> either way, the memory use between the two zones is unbalanced. On an
> 8GB box it may be reasonable to keep the lomem zone for non-himem
> allocations, but on 2GB we probably want to allocate page cache and user
> pages as fairly as possible above and below 1GB.
>
> --Stephen
> --
> 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/
>
--
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:[~2000-03-20 20:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-13 22:50 Ben LaHaise
2000-03-13 22:55 ` Linus Torvalds
2000-03-13 23:28 ` Kanoj Sarcar
2000-03-13 23:31 ` Linus Torvalds
2000-03-14 0:23 ` Kanoj Sarcar
2000-03-14 0:32 ` Linus Torvalds
2000-03-17 12:35 ` Stephen C. Tweedie
2000-03-20 20:58 ` Kanoj Sarcar [this message]
2000-03-20 21:31 ` Linus Torvalds
2000-03-20 22:06 ` Linus Torvalds
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=200003202058.MAA47885@google.engr.sgi.com \
--to=kanoj@google.engr.sgi.com \
--cc=bcrl@redhat.com \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
--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