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