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