public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@novell.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: ZONE_PADDING wastes 4 bytes of the new cacheline
Date: Sat, 23 Oct 2004 11:59:55 +0200	[thread overview]
Message-ID: <20041023095955.GR14325@dualathlon.random> (raw)
In-Reply-To: <4179DF23.4030402@yahoo.com.au>

On Sat, Oct 23, 2004 at 02:33:39PM +1000, Nick Piggin wrote:
> Andrea Arcangeli wrote:
> >I don't see any benefit in limiting the high order, infact it seems a
> >bad bug. If something you should limit the _small_ order, so that the
> >high order will have a slight chance to succeed. You're basically doing
> >the opposite.
> >
> 
> You need the order there so someone can't allocate a huge amount
> of memory and deplete all your reserves and crash the system.

what? the point of alloc_pages is to allow people to allocate memory,
what's the difference of 1 2M allocation and 512 4k allocations? No
difference at all. Infact if something the 512 4k allocations hurts a
lot more since they can fragment the memory, while the single 2M
allocation will not fragment the memory. So if you really want to limit
something you should do the exact opposite of what the allocator is
doing.

> For day to day running, it should barely make a difference because
> the watermarks will be an order of magnitude larger.

yes, it makes little difference, this is why it doesn't hurt that much.

> AFAIKS, pages_min, pages_low and pages_high are all required for
> what we want to be doing. I don't see you you could remove any one
> of them and still have everything functioning properly....
> 
> I haven't really looked at 2.4 or your patches though. Maybe I
> misunderstood you.

2.4 has everything functionally properly but it has no
pages_min/low/high, it only has the watermarks. Infact the watermarks
_are_ low/min/high. That's what I'm forward porting to 2.6 (besides
fixing minor mostly not noticeable but harmful bits like the order
nosense described above).

  reply	other threads:[~2004-10-23 10:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-21  1:17 ZONE_PADDING wastes 4 bytes of the new cacheline Andrea Arcangeli
2004-10-21  3:10 ` Nick Piggin
2004-10-21  4:36   ` Andrew Morton
2004-10-21  4:53     ` Nick Piggin
2004-10-21 10:51     ` Mikael Pettersson
2004-10-21 12:45       ` Andrea Arcangeli
2004-10-21 18:54         ` Adam Heath
2004-10-21 20:21           ` DaMouse
2004-10-21 21:24             ` Jon Masters
2004-10-22 10:09               ` DaMouse
2004-10-21 22:26     ` Nick Piggin
2004-10-21 22:45       ` Andrea Arcangeli
2004-10-22  0:34         ` Nick Piggin
2004-10-22  1:10           ` Andrea Arcangeli
2004-10-22  1:26             ` Andrew Morton
2004-10-22  2:55               ` Jesse Barnes
2004-10-22  3:38                 ` Nick Piggin
2004-10-22  3:49                   ` Jesse Barnes
2004-10-22 17:15                     ` Andrea Arcangeli
2004-10-22  3:09               ` Nick Piggin
2004-10-22  3:26                 ` Andrew Morton
2004-10-22  3:35                   ` Nick Piggin
2004-10-22 17:13                     ` Andrea Arcangeli
2004-10-22 17:07                   ` Andrea Arcangeli
2004-10-22 15:50               ` Andrea Arcangeli
2004-10-22  3:02             ` Nick Piggin
2004-10-22 16:58               ` Andrea Arcangeli
2004-10-23  4:33                 ` Nick Piggin
2004-10-23  9:59                   ` Andrea Arcangeli [this message]
2004-10-23 10:22                     ` Nick Piggin
2004-10-23 11:03                       ` Andrea Arcangeli
2004-10-23 16:28                         ` Nick Piggin
2004-10-25 12:44                           ` Andrea Arcangeli
2004-10-25 12:49                             ` Nick Piggin
2004-10-25 13:51                               ` Andrea Arcangeli
2004-10-25 20:09                             ` Robert White

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=20041023095955.GR14325@dualathlon.random \
    --to=andrea@novell.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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