From: Manfred Spraul <manfred@colorfullife.com>
To: linux-mm@kvack.org
Subject: [PATCH] modified memory_pressure calculation
Date: Sun, 27 May 2001 14:30:09 +0200 [thread overview]
Message-ID: <3B10F351.6DDEC59@colorfullife.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
I think the current memory_pressure calculation is broken - at least
memory_pressure does not contain the number of pages necessary in the
inactive_clean_list to handle 1 second of allocations.
* if reclaim_page() finds a page that is Referenced, Dirty or Locked
then it must increase memory_pressure.
* I don't understand the purpose of the second ++ in alloc_pages().
What about the attached patch [vs. 2.4.5]? It's just an idea, untested.
If the behaviour is worse then we must figure out what memory_pressure
actually is under the various workloads. AFAICS it has nothing to do
with the number of memory allocations per second.
Please cc me, I'm not subscribed to linux-mm.
--
Manfred
[-- Attachment #2: patch-memory_pressure --]
[-- Type: text/plain, Size: 3727 bytes --]
diff -u 2.4/mm/page_alloc.c build-2.4/mm/page_alloc.c
--- 2.4/mm/page_alloc.c Sat May 26 10:06:29 2001
+++ build-2.4/mm/page_alloc.c Sun May 27 14:18:35 2001
@@ -141,8 +141,11 @@
* since it's nothing important, but we do want to make sure
* it never gets negative.
*/
- if (memory_pressure > NR_CPUS)
- memory_pressure--;
+ {
+ int mp = memory_pressure-(1<<order);
+ if (mp > 0)
+ memory_pressure = mp;
+ }
}
#define MARK_USED(index, order, area) \
@@ -282,7 +285,7 @@
/*
* Allocations put pressure on the VM subsystem.
*/
- memory_pressure++;
+ memory_pressure += (1<<order);
/*
* (If anyone calls gfp from interrupts nonatomically then it
@@ -437,7 +440,6 @@
* the inactive clean list. (done by page_launder)
*/
if (gfp_mask & __GFP_WAIT) {
- memory_pressure++;
try_to_free_pages(gfp_mask);
goto try_again;
}
@@ -476,7 +478,7 @@
/* XXX: is pages_min/4 a good amount to reserve for this? */
if (z->free_pages < z->pages_min / 4 &&
- !(current->flags & PF_MEMALLOC))
+ (in_interrupt() || !(current->flags & PF_MEMALLOC)))
continue;
page = rmqueue(z, order);
if (page)
diff -u 2.4/mm/swap.c build-2.4/mm/swap.c
--- 2.4/mm/swap.c Mon Jan 22 22:30:21 2001
+++ build-2.4/mm/swap.c Sun May 27 14:24:29 2001
@@ -46,8 +46,19 @@
* is doing, averaged over a minute. We use this to determine how
* many inactive pages we should have.
*
- * In reclaim_page and __alloc_pages: memory_pressure++
+ * In __alloc_pages: memory_pressure++
+ * each allocation uses memory
* In __free_pages_ok: memory_pressure--
+ * kreclaimd: memory_pressure++ before __free_pages_ok
+ * A memory free from outside of the {in,}active_list
+ * reduces the necessary number of freeable pages in the
+ * inactive_clean_list.
+ * in reclaim_pages: memory_pressure++ for each unfreeable page found
+ * in the inactive_clean_list.
+ * Pages in the inactive_clean_list can be reused by the current
+ * owner. This "increases" the memory pressure since more pages
+ * must be in the inactive_clean_list to have a certain number of
+ * freeable pages in the inactive_clean_list.
* In recalculate_vm_stats the value is decayed (once a second)
*/
int memory_pressure;
diff -u 2.4/mm/vmscan.c build-2.4/mm/vmscan.c
--- 2.4/mm/vmscan.c Sat May 26 10:06:29 2001
+++ build-2.4/mm/vmscan.c Sun May 27 14:27:23 2001
@@ -355,6 +355,7 @@
printk("VM: reclaim_page, wrong page on list.\n");
list_del(page_lru);
page->zone->inactive_clean_pages--;
+ memory_pressure++;
continue;
}
@@ -363,6 +364,7 @@
(!page->buffers && page_count(page) > 1)) {
del_page_from_inactive_clean_list(page);
add_page_to_active_list(page);
+ memory_pressure++;
continue;
}
@@ -370,6 +372,7 @@
if (page->buffers || PageDirty(page) || TryLockPage(page)) {
del_page_from_inactive_clean_list(page);
add_page_to_inactive_dirty_list(page);
+ memory_pressure++;
continue;
}
@@ -389,6 +392,7 @@
list_del(page_lru);
zone->inactive_clean_pages--;
UnlockPage(page);
+ memory_pressure++;
}
/* Reset page pointer, maybe we encountered an unfreeable page. */
page = NULL;
@@ -404,7 +408,6 @@
out:
spin_unlock(&pagemap_lru_lock);
spin_unlock(&pagecache_lock);
- memory_pressure++;
return page;
}
@@ -1046,6 +1049,14 @@
page = reclaim_page(zone);
if (!page)
break;
+ /* We move pages from the inactive_clean_list
+ * into the buddy. This doesn't cause any change
+ * in the actual memory pressure.
+ * The 'memory_pressure++' is
+ * required to undo the 'memory_pressure--'
+ * in __free_pages_ok.
+ */
+ memory_pressure++;
__free_page(page);
}
}
next reply other threads:[~2001-05-27 12:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-27 12:30 Manfred Spraul [this message]
2001-05-27 15:58 ` Rik van Riel
2001-05-27 17:44 ` Manfred Spraul
2001-05-27 17:51 ` Rik van Riel
2001-05-27 18:24 ` Manfred Spraul
2001-05-27 18:40 ` Rik van Riel
2001-05-28 17:29 ` Marcelo Tosatti
2001-05-28 19:20 ` Manfred Spraul
2001-05-28 18:07 ` Marcelo Tosatti
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=3B10F351.6DDEC59@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=linux-mm@kvack.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