public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: William Lee Irwin III <wli@holomorphy.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Takashi Iwai <tiwai@suse.de>, Andi Kleen <ak@suse.de>,
	ak@muc.de, tripperda@nvidia.com, discuss@x86-64.org,
	linux-kernel@vger.kernel.org
Subject: Re: [discuss] Re: 32-bit dma allocations on 64-bit platforms
Date: Thu, 24 Jun 2004 20:07:56 +0200	[thread overview]
Message-ID: <20040624180756.GS30687@dualathlon.random> (raw)
In-Reply-To: <20040624175331.GI21066@holomorphy.com>

On Thu, Jun 24, 2004 at 10:53:31AM -0700, William Lee Irwin III wrote:
> On Thu, Jun 24, 2004 at 07:39:27PM +0200, Andrea Arcangeli wrote:
> > I looked more into it and you can leave it turned off since it's not
> > going to work.
> > it's all in functions of z->pages_* and those are _global_ for all the
> > zones, and in turn they're absolutely meaningless.
> > the algorithm has nothing in common with lowmem_reverse_ratio, the
> > effect has a tinybit of similarity but the incremntal min thing is so
> > weak and so bad that it will either not help or it'll waste tons of
> > memory. Furthemore you cannot set a sysctl value that works for all
> > machines. The whole thing should be dropped and replaced with the fine
> > production quality lowmem_reserve_ratio in 2.4.26+
> > (the only broken thing of lowmem_reserve_ratio is that it cannot be
> > tuned, not even at boottime, a recompile is needed, but that's fixable
> > to tune it at boot time, and in theory at runtime too, but the point is
> > that no dyanmic tuning is required with it)
> > Please focus on this code of 2.4:
> 
> There is mention of discrimination between pinned and unpinned
> allocations not being possible; I can arrange this for more
> comprehensive coverage if desired. Would you like this to be arranged,
> and if so, how would you like that to interact with the fallback
> heuristics?

how do you handle swapoff and mlock then? anonymous memory is pinned w/o
swap. You've relocate the stuff during the mlock or swapoff to obey to
the pin limits to make this work right, and it sounds quite complicated
and it would hurt mlock performance a lot too (some big app uses mlock
to pagein w/o page faults tons of stuff).

Note that the "pinned" thing in theory makes *perfect* sense, but it
only makes sense on _top_ of lowmem_zone_reserve_ratio, it's not an
alternative.

When the page is pinned you obey to the "lowmem_zone_reserve_ratio" when
it's _not_ pinned then you absolutely ignore the
lowmem_zone_reseve_ratio and you go with the watermarks[curr_zone_idx]
instead of the class_idx.

But in practice I doubt it worth it since I doubt you want to relocate
pagecache and anonymous memory during swapoff/mlock.

  reply	other threads:[~2004-06-24 18:07 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m3acyu6pwd.fsf@averell.firstfloor.org>
     [not found] ` <20040623213643.GB32456@hygelac>
2004-06-23 23:46   ` 32-bit dma allocations on 64-bit platforms Andi Kleen
2004-06-24 11:13     ` Takashi Iwai
2004-06-24 11:29       ` [discuss] " Andi Kleen
2004-06-24 14:36         ` Takashi Iwai
2004-06-24 14:42           ` Andi Kleen
2004-06-24 14:58             ` Takashi Iwai
2004-06-24 15:29               ` Andrea Arcangeli
2004-06-24 15:48                 ` Nick Piggin
2004-06-24 16:52                   ` Andrea Arcangeli
2004-06-24 16:56                     ` William Lee Irwin III
2004-06-24 17:32                       ` Andrea Arcangeli
2004-06-24 17:38                         ` William Lee Irwin III
2004-06-24 18:02                           ` Andrea Arcangeli
2004-06-24 18:13                             ` William Lee Irwin III
2004-06-24 18:27                               ` Andrea Arcangeli
2004-06-24 18:50                                 ` William Lee Irwin III
2004-06-24 21:54                       ` Andrew Morton
2004-06-24 22:08                         ` William Lee Irwin III
2004-06-24 22:45                           ` Andrea Arcangeli
2004-06-24 22:51                             ` William Lee Irwin III
2004-06-24 23:09                               ` Andrew Morton
2004-06-24 23:15                                 ` William Lee Irwin III
2004-06-25  6:16                                   ` William Lee Irwin III
2004-06-25  2:39                                 ` Andrea Arcangeli
2004-06-25  2:47                                   ` Andrew Morton
2004-06-25  3:19                                     ` Andrea Arcangeli
2004-06-24 22:11                         ` Andrew Morton
2004-06-24 23:09                           ` Andrea Arcangeli
2004-06-25  1:17                             ` Nick Piggin
2004-06-25  3:11                               ` Andrea Arcangeli
2004-06-24 22:21                         ` Andrea Arcangeli
2004-06-24 22:36                           ` Andrew Morton
2004-06-24 23:15                             ` Andrea Arcangeli
2004-06-24 22:37                           ` William Lee Irwin III
2004-06-24 22:40                             ` William Lee Irwin III
2004-06-24 23:21                             ` Andrea Arcangeli
2004-06-24 23:45                               ` William Lee Irwin III
2004-06-24 17:39                   ` Andrea Arcangeli
2004-06-24 17:53                     ` William Lee Irwin III
2004-06-24 18:07                       ` Andrea Arcangeli [this message]
2004-06-24 18:29                         ` William Lee Irwin III
2004-06-24 16:04                 ` Takashi Iwai
2004-06-24 17:16                   ` Andrea Arcangeli
2004-06-24 18:33                     ` Takashi Iwai
2004-06-24 18:44                       ` Andrea Arcangeli
2004-06-25 15:50                         ` Takashi Iwai
2004-06-25 17:30                           ` Andrea Arcangeli
2004-06-25 17:39                             ` Takashi Iwai
2004-06-25 17:45                               ` Andrea Arcangeli
2004-06-24 14:45       ` Terence Ripperda
2004-06-24 15:41         ` Andrea Arcangeli
2004-06-24 15:44     ` Terence Ripperda
2004-06-24 16:15       ` [discuss] " Andi Kleen
2004-06-24 17:22         ` Andrea Arcangeli
2004-06-24 22:28         ` Terence Ripperda
2004-06-24 18:51       ` Andi Kleen
2004-06-26  4:58         ` David Mosberger
2004-06-24 13:48 Jesse Barnes
2004-06-24 14:39 ` Terence Ripperda
2004-06-24 15:01   ` [discuss] " Andi Kleen

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=20040624180756.GS30687@dualathlon.random \
    --to=andrea@suse.de \
    --cc=ak@muc.de \
    --cc=ak@suse.de \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=tiwai@suse.de \
    --cc=tripperda@nvidia.com \
    --cc=wli@holomorphy.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