From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>
Cc: Linux Memory Management <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat
Date: Sun, 05 Sep 2004 15:44:18 +1000 [thread overview]
Message-ID: <413AA7B2.4000907@yahoo.com.au> (raw)
Kswapd is dumb as bricks when it comes to higher order allocations.
Actually that's not quite fair: it is bad at lots of things... but
higher order allocations are one of its more spectacular failures.
The major problem that I can see is with !wait allocations, where
you aren't allowed to free anything yourself - you're relying on
kswapd (aside from that, it's always nice to avoid synchronous reclaim).
Apparently these (higher-order && !wait) come up mainly in networking
which is the thing I had in mind. *However* as I only have half of a
gigabit network (ie. 1 card), I haven't done any testing where it
really counts. I'm also seeing surprisingly few reports on lkml, so
perhaps it is me that needs the beating?
Anyway, the big failure case is when memory is fragmented to the
point that pages_free > pages_low, but you still have no higher order
pages left. In that case, your !wait allocations can keep calling
wakeup_kswapd but he'll just keep sleeping. min_free_kbytes is not
really a solution because it just raises pages_low. In a nutshell,
that whole area doesn't really have any idea about higher order
allocations.
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?)
*Also*, if we have requested an order 5 allocation, but one isn't
available, we'll get kswapd to try to free at least 1, even if its
order-5 "free-until" watermark is 0KB.
The main cost is keeping track of the number of free pages of each order.
There is also a penalty in the allocator for order > 0 allocations, but
I have tried to do it so lower order allocations need to do less work.
Flames? Comments?
--
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>
next reply other threads:[~2004-09-05 5:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-05 5:44 Nick Piggin [this message]
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:20 ` Nick Piggin
2004-09-05 5:50 ` [RFC][PATCH 2/3] alloc-order watermarks Nick Piggin
2004-09-05 6:13 ` [RFC][PATCH 1/3] account free buddy areas 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:16 ` Nick Piggin
2004-09-05 10:13 ` Nick Piggin
2004-09-05 17:24 ` Linus Torvalds
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 18:41 ` Arjan van de Ven
2004-09-06 1:35 ` Nick Piggin
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:39 ` Arjan van de Ven
2004-09-15 14:18 ` Jörn Engel
2004-09-06 1:09 ` Nick Piggin
2004-09-05 6:09 ` Andrew Morton
2004-09-05 6:26 ` Nick Piggin
2004-09-05 6:27 ` Anton Blanchard
2004-09-05 10:09 ` Nick Piggin
2004-09-06 3:33 ` David S. Miller
2004-09-06 8:55 ` Nick Piggin
2004-09-05 16:49 ` Linus Torvalds
2004-09-06 0:54 ` 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=413AA7B2.4000907@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox