From: Mike Fedyk <mfedyk@matchmail.com>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.3-mm3
Date: Wed, 25 Feb 2004 18:34:52 -0800 [thread overview]
Message-ID: <403D5B4C.3020309@matchmail.com> (raw)
In-Reply-To: <403D5174.6050302@cyberone.com.au>
[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]
Nick Piggin wrote:
>
>
> Mike Fedyk wrote:
>
>> Nick Piggin wrote:
>>
>>>
>>>
>>> That is a much better sounding ratio. Of course that doesn't mean much
>>> if performance is worse. Slab might be getting reclaimed a little bit
>>> too hard vs pagecache now.
>>>
>>
>> I'll let you know. My graphs are looking better, except for one
>> instance of Xvnc (for one user -- I'm still tracking that one down)
>> hitting a memory grabbing loop that made me kill it.
>>
>
> Try to get /proc/meminfo and a sysrq + T trace if something like
> this happens.
I'll do that next time.
When did /proc/sysrq-trigger get in the kernel? forgot about that at
the time :(
>
>>>> See:
>>>> http://www.matchmail.com/stats/lrrd/matchmail.com/srv-lnx2600.matchmail.com-memory.html
>>>>
>>>>
>>>> Is there any way I can get the VM patches against 2.6.3? I'm not
>>>> comfortable with running -mm3 on this production server, especially
>>>> seeing the "sync hang" bug.
>>>>
>>>
>>> Well your server wasn't going too badly with 2.6.3, wasn't it? Might
>>> as well just wait for them to get into the the tree.
>>
>>
>>
>> I might as well take out the third 512MB DIMM in that machine then...
>>
>> Any chance you could post a VM patch roll-up against 2.6.3 for little
>> ole me?
>>
>
> It is a bit easier said than done as you might have seen :P And
> I'm laz^W^W I happen to not agree with one of Andrew's patches,
> so it would go against all my principles ;)
>
> IMO, shrink_slab-for-all-zones.patch and zone-balancing-fix.patch
> should be all you need although they won't shrink the slab as
> much as mm3. They should be pretty easy to port by hand.
OK, I'll give that a try.
Is the attached patch the latest version of your alternative patch
instead of shrink_slab-for-all-zones.patch?
[-- Attachment #2: vm-shrink-slab-lowmem.patch --]
[-- Type: text/x-patch, Size: 5212 bytes --]
linux-2.6-npiggin/include/linux/mm.h | 2 -
linux-2.6-npiggin/mm/page_alloc.c | 11 ------
linux-2.6-npiggin/mm/vmscan.c | 64 ++++++++++++++++++++++++++++-------
3 files changed, 52 insertions(+), 25 deletions(-)
diff -puN mm/vmscan.c~vm-shrink-slab-lowmem mm/vmscan.c
--- linux-2.6/mm/vmscan.c~vm-shrink-slab-lowmem 2004-02-22 16:35:06.000000000 +1100
+++ linux-2.6-npiggin/mm/vmscan.c 2004-02-22 17:30:53.000000000 +1100
@@ -122,7 +122,25 @@ void remove_shrinker(struct shrinker *sh
}
EXPORT_SYMBOL(remove_shrinker);
-
+
+/*
+ * Returns the number of lowmem pages which are on the lru lists
+ */
+static unsigned int nr_lowmem_lru_pages(void)
+{
+ unsigned int pages = 0;
+ struct zone *zone;
+
+ for_each_zone(zone) {
+ if (unlikely(is_highmem(zone)))
+ continue;
+ pages += zone->nr_active + zone->nr_inactive;
+ }
+
+ return pages;
+}
+
+
#define SHRINK_BATCH 128
/*
* Call the shrink functions to age shrinkable caches
@@ -136,6 +154,24 @@ EXPORT_SYMBOL(remove_shrinker);
* slab to avoid swapping.
*
* We do weird things to avoid (scanned*seeks*entries) overflowing 32 bits.
+ *
+ * The formula to work out how much to scan each slab is as follows:
+ * Let S be the number of lowmem LRU pages were scanned (scanned)
+ * Let M be the total number of lowmem LRU pages (pages)
+ * T be the total number of all slab items.
+ * For each slab:
+ * I be number of slab items ((*shrinker->shrinker)(0, gfp_mask))
+ *
+ * "S * M / T" then gives the total number of slab items to scan, N
+ * Then for each slab, "N * T / I" is the number of items to scan for this slab.
+ *
+ * This simplifies to "S * M / I", or
+ * lowmem lru scanned * items in this slab / total lowmem lru pages
+ *
+ * TODO:
+ * The value of M should be calculated *before* LRU scanning.
+ * Total number of items in each slab should be used, not just freeable ones.
+ * Unfreeable slab items should not count toward the scanning total.
*/
static int shrink_slab(unsigned long scanned, unsigned int gfp_mask)
{
@@ -145,14 +181,16 @@ static int shrink_slab(unsigned long sca
if (down_trylock(&shrinker_sem))
return 0;
- pages = nr_used_zone_pages();
+ pages = nr_lowmem_lru_pages();
list_for_each_entry(shrinker, &shrinker_list, list) {
unsigned long long delta;
delta = 4 * scanned / shrinker->seeks;
delta *= (*shrinker->shrinker)(0, gfp_mask);
do_div(delta, pages + 1);
- shrinker->nr += delta;
+
+ /* +1 to ensure some scanning gets done */
+ shrinker->nr += delta + 1;
if (shrinker->nr > SHRINK_BATCH) {
long nr_to_scan = shrinker->nr;
@@ -857,7 +895,8 @@ shrink_zone(struct zone *zone, unsigned
*/
static int
shrink_caches(struct zone **zones, int priority, int *total_scanned,
- int gfp_mask, int nr_pages, struct page_state *ps)
+ int *lowmem_scanned, int gfp_mask, int nr_pages,
+ struct page_state *ps)
{
int ret = 0;
int i;
@@ -875,7 +914,10 @@ shrink_caches(struct zone **zones, int p
ret += shrink_zone(zone, gfp_mask,
to_reclaim, &nr_scanned, ps, priority);
+
*total_scanned += nr_scanned;
+ if (i < ZONE_HIGHMEM)
+ *lowmem_scanned += nr_scanned;
if (ret >= nr_pages)
break;
}
@@ -915,19 +957,17 @@ int try_to_free_pages(struct zone **zone
zones[i]->temp_priority = DEF_PRIORITY;
for (priority = DEF_PRIORITY; priority >= 0; priority--) {
- int total_scanned = 0;
+ int total_scanned = 0, lowmem_scanned = 0;
struct page_state ps;
get_page_state(&ps);
nr_reclaimed += shrink_caches(zones, priority, &total_scanned,
- gfp_mask, nr_pages, &ps);
+ &lowmem_scanned, gfp_mask, nr_pages, &ps);
- if (zones[0] - zones[0]->zone_pgdat->node_zones < ZONE_HIGHMEM) {
- shrink_slab(total_scanned, gfp_mask);
- if (reclaim_state) {
- nr_reclaimed += reclaim_state->reclaimed_slab;
- reclaim_state->reclaimed_slab = 0;
- }
+ shrink_slab(lowmem_scanned, gfp_mask);
+ if (reclaim_state) {
+ nr_reclaimed += reclaim_state->reclaimed_slab;
+ reclaim_state->reclaimed_slab = 0;
}
if (nr_reclaimed >= nr_pages) {
diff -puN mm/page_alloc.c~vm-shrink-slab-lowmem mm/page_alloc.c
--- linux-2.6/mm/page_alloc.c~vm-shrink-slab-lowmem 2004-02-22 16:35:06.000000000 +1100
+++ linux-2.6-npiggin/mm/page_alloc.c 2004-02-22 17:04:43.000000000 +1100
@@ -772,17 +772,6 @@ unsigned int nr_free_pages(void)
EXPORT_SYMBOL(nr_free_pages);
-unsigned int nr_used_zone_pages(void)
-{
- unsigned int pages = 0;
- struct zone *zone;
-
- for_each_zone(zone)
- pages += zone->nr_active + zone->nr_inactive;
-
- return pages;
-}
-
#ifdef CONFIG_NUMA
unsigned int nr_free_pages_pgdat(pg_data_t *pgdat)
{
diff -puN include/linux/mm.h~vm-shrink-slab-lowmem include/linux/mm.h
--- linux-2.6/include/linux/mm.h~vm-shrink-slab-lowmem 2004-02-22 16:35:06.000000000 +1100
+++ linux-2.6-npiggin/include/linux/mm.h 2004-02-22 17:04:26.000000000 +1100
@@ -625,8 +625,6 @@ static inline struct vm_area_struct * fi
extern struct vm_area_struct *find_extend_vma(struct mm_struct *mm, unsigned long addr);
-extern unsigned int nr_used_zone_pages(void);
-
extern struct page * vmalloc_to_page(void *addr);
extern struct page * follow_page(struct mm_struct *mm, unsigned long address,
int write);
_
next prev parent reply other threads:[~2004-02-26 2:36 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-23 1:22 2.6.3-mm3 Andrew Morton
2004-02-23 1:43 ` 2.6.3-mm3 Nick Piggin
2004-02-23 1:55 ` 2.6.3-mm3 Andrew Morton
2004-02-23 2:02 ` 2.6.3-mm3 Nick Piggin
2004-02-23 2:51 ` 2.6.3-mm3 Nick Piggin
2004-02-23 3:04 ` 2.6.3-mm3 Nick Piggin
2004-02-23 8:08 ` 2.6.3-mm3 Nick Piggin
2004-02-23 8:48 ` [PATCH] vm-fix-all_zones_ok (was Re: 2.6.3-mm3) Nick Piggin
2004-02-23 8:59 ` Andrew Morton
2004-02-23 9:21 ` Nick Piggin
2004-02-23 9:24 ` Andrew Morton
2004-02-23 16:23 ` Bill Davidsen
2004-02-23 22:47 ` Chris Wedgwood
2004-02-24 4:11 ` Nick Piggin
2004-02-24 9:12 ` Chris Wedgwood
2004-02-24 9:22 ` Andrew Morton
2004-02-24 9:30 ` Chris Wedgwood
2004-02-24 9:37 ` Andrew Morton
2004-02-24 20:55 ` Rik van Riel
2004-02-24 22:36 ` Andrew Morton
2004-02-24 22:41 ` Rik van Riel
2004-02-23 2:19 ` 2.6.3-mm3 Christoph Hellwig
2004-02-23 2:52 ` 2.6.3-mm3 Joshua Kwan
2004-02-23 3:34 ` 2.6.3-mm3 Joshua Kwan
2004-02-23 18:09 ` [patch] 2.6.3-mm3: ALSA miXart driver doesn't compile Adrian Bunk
2004-02-23 18:58 ` 2.6.3-mm3 (compile stats) John Cherry
2004-02-23 20:00 ` Sam Ravnborg
2004-02-24 22:22 ` 2.6.3-mm3 Mike Fedyk
2004-02-24 22:30 ` 2.6.3-mm3 Andrew Morton
2004-02-25 21:27 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 1:06 ` 2.6.3-mm3 Nick Piggin
2004-02-26 1:18 ` 2.6.3-mm3 Marc-Christian Petersen
2004-02-26 1:28 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 1:32 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 1:52 ` 2.6.3-mm3 Nick Piggin
2004-02-26 2:34 ` Mike Fedyk [this message]
2004-02-26 2:40 ` 2.6.3-mm3 Nick Piggin
2004-02-26 2:48 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 3:05 ` 2.6.3-mm3 Nick Piggin
2004-02-26 3:19 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 3:29 ` 2.6.3-mm3 Nick Piggin
2004-02-26 4:08 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 4:56 ` 2.6.3-mm3 Mike Fedyk
2004-02-27 19:02 ` 2.6.3-mm3 Mike Fedyk
2004-02-27 21:57 ` 2.6.3-mm3 Nick Piggin
2004-02-25 0:26 ` 2.6.3-mm3 hangs on boot x440 (scsi?) john stultz
2004-02-25 1:06 ` Andrew Morton
2004-02-25 1:22 ` john stultz
2004-02-25 1:27 ` john stultz
2004-02-25 1:48 ` Andrew Morton
2004-02-25 22:15 ` john stultz
2004-02-26 14:40 ` Go Taniguchi
2004-02-26 21:26 ` john stultz
2004-02-26 23:02 ` john stultz
2004-02-26 23:15 ` Matthew Wilcox
2004-02-27 0:14 ` john stultz
2004-02-27 0:58 ` john stultz
2004-02-27 2:25 ` john stultz
2004-02-25 1:15 ` [PATCH 2.6.3-mm3] serialize_writeback_fdatawait patch Daniel McNeil
2004-02-25 1:43 ` Andrew Morton
2004-02-25 22:56 ` Daniel McNeil
2004-02-25 2:51 ` 2.6.3-mm3 Mike Fedyk
2004-02-25 3:09 ` 2.6.3-mm3 Andrew Morton
2004-02-25 3:34 ` 2.6.3-mm3 Mike Fedyk
2004-02-25 10:47 ` 2.6.3-mm3 sometimes freeze on "sync" Helge Hafting
2004-02-25 9:39 ` Andrew Morton
2004-02-26 8:49 ` Helge Hafting
2004-02-27 14:49 ` Alexander Hoogerhuis
2004-02-27 23:34 ` 2.6.3-mm3 john stultz
2004-02-28 0:06 ` 2.6.3-mm3 Andrew Morton
2004-02-28 2:48 ` 2.6.3-mm3 (ioremap failure w/ _X86_4G and _NUMA) john stultz
2004-02-28 3:18 ` Dave Hansen
2004-02-28 4:34 ` Martin J. Bligh
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=403D5B4C.3020309@matchmail.com \
--to=mfedyk@matchmail.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
/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