mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrea Arcangeli <andrea@novell.com>
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 20:22:38 +1000	[thread overview]
Message-ID: <417A30EE.1030205@yahoo.com.au> (raw)
In-Reply-To: <20041023095955.GR14325@dualathlon.random>

Andrea Arcangeli wrote:
> 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.
> 

It is an unlikely scenario, but it is definitely good for robustness.
Especially on small memory systems where the amount allocated doesn't
have to be that large.

Let's say a 16MB system pages_low ~= 64K, so we'll also say we've
currently got 64K free. Someone then wants to do an order 4 allocation
OK they succeed (assuming memory isn't fragmented) and there's 0K free.

Which is bad because you can now get deadlocks when trying to free
memory.

> 
>>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).
> 

Oh if you've still got the three watermarks then that may work -
I thought you meant getting rid of one of the *completely*.

But I'm still not sure what advantage you see in moving from
pages_xxx + protection to a single watermark.

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

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-21  1:17 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
2004-10-23 10:22                     ` Nick Piggin [this message]
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=417A30EE.1030205@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=andrea@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    /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

Powered by JetHome