All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: "David S. Miller" <davem@davemloft.net>,
	akpm@osdl.org, torvalds@osdl.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat
Date: Sun, 05 Sep 2004 20:13:59 +1000	[thread overview]
Message-ID: <413AE6E7.5070103@yahoo.com.au> (raw)
In-Reply-To: <413AAF49.5070600@yahoo.com.au>

Nick Piggin wrote:
> David S. Miller wrote:
> 
>> On Sun, 05 Sep 2004 15:44:18 +1000
>> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>>
>>
>>> So my solution? Just teach kswapd and the watermark code about higher
>>> order allocations in a fairly simple way. If pages_low is (say), 1024KB,
>>> we now also require 512KB of order-1 and above pages, 256K of order-2
>>> and up, 128K of order 3, etc. (perhaps we should stop at about order-3?)
>>
>>
>>
>> Whether to stop at order 3 is indeed an interesting question.
>>
>> The reality is that the high-order allocations come mostly from folks
>> using jumbo 9K MTUs on gigabit and faster technologies.  On x86, an
>> order 2 would cover those packet allocations, but on sparc64 for example
>> order 1 would be enough, whereas on a 2K PAGE_SIZE system order 3 would
>> be necessary.
>>
> 
> Yeah I see.
> 

Hmm, and the crowning argument for not stopping at order 3 is that if we
never use higher order allocations, nothing will care about their watermarks
anyway. I think I had myself confused when that question in the first place.

So yeah, stopping at a fixed number isn't required, and as you say it keeps
things general and special cases minimal.

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: "David S. Miller" <davem@davemloft.net>,
	akpm@osdl.org, torvalds@osdl.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat
Date: Sun, 05 Sep 2004 20:13:59 +1000	[thread overview]
Message-ID: <413AE6E7.5070103@yahoo.com.au> (raw)
In-Reply-To: <413AAF49.5070600@yahoo.com.au>

Nick Piggin wrote:
> David S. Miller wrote:
> 
>> On Sun, 05 Sep 2004 15:44:18 +1000
>> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>>
>>
>>> So my solution? Just teach kswapd and the watermark code about higher
>>> order allocations in a fairly simple way. If pages_low is (say), 1024KB,
>>> we now also require 512KB of order-1 and above pages, 256K of order-2
>>> and up, 128K of order 3, etc. (perhaps we should stop at about order-3?)
>>
>>
>>
>> Whether to stop at order 3 is indeed an interesting question.
>>
>> The reality is that the high-order allocations come mostly from folks
>> using jumbo 9K MTUs on gigabit and faster technologies.  On x86, an
>> order 2 would cover those packet allocations, but on sparc64 for example
>> order 1 would be enough, whereas on a 2K PAGE_SIZE system order 3 would
>> be necessary.
>>
> 
> Yeah I see.
> 

Hmm, and the crowning argument for not stopping at order 3 is that if we
never use higher order allocations, nothing will care about their watermarks
anyway. I think I had myself confused when that question in the first place.

So yeah, stopping at a fixed number isn't required, and as you say it keeps
things general and special cases minimal.
--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-09-05 10:15 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-05  5:44 [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat Nick Piggin
2004-09-05  5:44 ` Nick Piggin
2004-09-05  5:45 ` [RFC][PATCH 1/3] account free buddy areas Nick Piggin
2004-09-05  5:46   ` [RFC][PATCH 2/3] alloc-order watermarks Nick Piggin
2004-09-05  5:47     ` [RFC][PATCH 3/3] teach kswapd about watermarks Nick Piggin
2004-09-05  6:04       ` David S. Miller
2004-09-05  6:04         ` David S. Miller
2004-09-05  6:20         ` Nick Piggin
2004-09-05  6:20           ` Nick Piggin
2004-09-05  5:50     ` [RFC][PATCH 2/3] alloc-order watermarks Nick Piggin
2004-09-05  5:50       ` Nick Piggin
2004-09-05  6:13   ` [RFC][PATCH 1/3] account free buddy areas Nick Piggin
2004-09-05  6:13     ` Nick Piggin
2004-09-05  6:02 ` [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat David S. Miller
2004-09-05  6:02   ` David S. Miller
2004-09-05  6:16   ` Nick Piggin
2004-09-05  6:16     ` Nick Piggin
2004-09-05 10:13     ` Nick Piggin [this message]
2004-09-05 10:13       ` Nick Piggin
2004-09-05 17:24       ` Linus Torvalds
2004-09-05 17:24         ` Linus Torvalds
2004-09-05 17:36         ` Martin J. Bligh
2004-09-05 17:36           ` Martin J. Bligh
2004-09-05 17:37         ` Arjan van de Ven
2004-09-05 17:58           ` Linus Torvalds
2004-09-05 17:58             ` Linus Torvalds
2004-09-05 18:41             ` Arjan van de Ven
2004-09-06  1:35             ` Nick Piggin
2004-09-06  1:35               ` Nick Piggin
2004-09-15 13:27             ` Jörn Engel
2004-09-15 13:27               ` Jörn Engel
2004-09-15 13:29               ` Arjan van de Ven
2004-09-15 13:34                 ` Jörn Engel
2004-09-15 13:34                   ` Jörn Engel
2004-09-15 13:39                   ` Arjan van de Ven
2004-09-15 14:18                     ` Jörn Engel
2004-09-15 14:18                       ` Jörn Engel
2004-09-06  1:09         ` Nick Piggin
2004-09-06  1:09           ` Nick Piggin
2004-09-05  6:09 ` Andrew Morton
2004-09-05  6:09   ` Andrew Morton
2004-09-05  6:26   ` Nick Piggin
2004-09-05  6:26     ` Nick Piggin
2004-09-05  6:27   ` Anton Blanchard
2004-09-05  6:27     ` Anton Blanchard
2004-09-05 10:09     ` Nick Piggin
2004-09-05 10:09       ` Nick Piggin
2004-09-06  3:33       ` David S. Miller
2004-09-06  3:33         ` David S. Miller
2004-09-06  8:55         ` Nick Piggin
2004-09-06  8:55           ` Nick Piggin
2004-09-05 16:49 ` Linus Torvalds
2004-09-05 16:49   ` Linus Torvalds
2004-09-06  0:54   ` Nick Piggin
2004-09-06  0:54     ` Nick Piggin
2004-09-06  1:49     ` Nick Piggin
2004-09-06  1:49       ` Nick Piggin

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=413AE6E7.5070103@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.