From: Con Kolivas <kernel@kolivas.org>
To: "Scott L. Burson" <gyro@zeta-soft.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Mathieu.Malaterre@creatis.insa-lyon.fr, Andrew Morton <akpm@osdl.org>
Subject: Re: SMP performance problem in 2.4 (was: Athlon spinlock performance)
Date: Sun, 3 Aug 2003 15:18:45 +1000 [thread overview]
Message-ID: <200308031518.45625.kernel@kolivas.org> (raw)
In-Reply-To: <16171.31418.271319.316382@kali.zeta-soft.com>
Hi Scott
On Sun, 3 Aug 2003 06:03, Scott L. Burson wrote:
> In one approximately 60-second period with the problematic workload
> running, `try_to_free_pages' was called 511 times. It made 2597 calls to
> `shrink_caches', which made 2592 calls to `shrink_cache' (i.e. it was very
> rare for `kmem_cache_reap' to release enough pages itself). The main loop
> of `shrink_cache' was executed -- brace yourselves -- 189 million times!
> During that time it called `page_cache_release' on only 31265 pages.
I noticed a curly section of the vm code when I was playing around with some
hacks that are in the -ck kernel and this section might be helpful as it
wasn't a hack so much as a fix in mm/vmscan.c around line 600. The problem
is when the priority drops to 1 it should do the most cache reaping but
instead bypasses some of it.
You could try this modification and see if it helps.
This isn't a real patch but you should get the idea.
Con
nr_pages -= kmem_cache_reap(gfp_mask);
- if (nr_pages <= 0)
- return 0;
+ if (nr_pages < 1)
+ goto shrinkcheck;
nr_pages = chunk_size;
/* try to keep the active list 2/3 of the size of the cache */
ratio = (unsigned long) nr_pages * nr_active_pages / ((nr_inactive_pages + 1) * 2);
refill_inactive(ratio);
nr_pages = shrink_cache(nr_pages, classzone, gfp_mask, priority);
- if (nr_pages <= 0)
- return 0;
+ /*
+ * Will return if nr_pages have been freed unless the
+ * priority managed to reach 1. If the vm is under this much
+ * pressure then shrink the d/i/dqcaches regardless. CK 2003
+ */
+shrinkcheck:
+ if (nr_pages < 1){
+ if (priority > 1)
+ return 0;
+ else
+ nr_pages = 0;
+ }
+
shrink_dcache_memory(priority, gfp_mask);
shrink_icache_memory(priority, gfp_mask);
next prev parent reply other threads:[~2003-08-03 5:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-02 20:03 SMP performance problem in 2.4 (was: Athlon spinlock performance) Scott L. Burson
2003-08-02 21:44 ` Andrew Morton
2003-08-03 10:00 ` Scott L. Burson
2003-08-06 2:37 ` Rik van Riel
2003-08-03 2:40 ` Rik van Riel
2003-08-03 5:18 ` Con Kolivas [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-08-06 17:21 Manfred Spraul
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=200308031518.45625.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=Mathieu.Malaterre@creatis.insa-lyon.fr \
--cc=akpm@osdl.org \
--cc=gyro@zeta-soft.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