From: Arjan van de Ven <arjanv@redhat.com>
To: riel@nl.linux.org
Subject: vm patch for highmem
Date: Tue, 28 Aug 2001 11:17:34 -0400 [thread overview]
Message-ID: <20010828111734.A5857@devserv.devel.redhat.com> (raw)
Hi
The patch below changes the highmem bouncebuffers to increase performance.
Initial reports are that it matters A LOT.
What it does: it 1) increases the emergemcy pool and 2) it tries to grab a
page from the pool for EVERY bounce first, until the pool is half empty, and
only THEN does it try to get a page from the VM.
While this penalizes the low zone by making it have less pages, it also
leaves the VM totally alone for normal loads; only under more extreme loads
does the vm get involved.
Comments?
Greetings,
Arjan van de Ven
--- linux/mm/highmem.c.org Thu Aug 23 09:23:11 2001
+++ linux/mm/highmem.c Thu Aug 23 10:21:33 2001
@@ -159,7 +159,11 @@
spin_unlock(&kmap_lock);
}
-#define POOL_SIZE 32
+#ifdef CONFIG_HIGHMEM64G
+#define POOL_SIZE 256
+#else
+#define POOL_SIZE 64
+#endif
/*
* This lock gets no contention at all, normally.
@@ -306,10 +310,24 @@
struct page *alloc_bounce_page (void)
{
struct list_head *tmp;
- struct page *page;
+ struct page *page = NULL;
+ int estimated_left;
+ int iteration=0;
repeat_alloc:
- page = alloc_page(GFP_NOIO);
+
+ spin_lock_irq(&emergency_lock);
+ estimated_left = nr_emergency_pages;
+ spin_unlock_irq(&emergency_lock);
+
+ /* If there are plenty of spare pages, use some of them first. If the
+ pool is at least half depleted, use the VM to allocate memory.
+ This allows moderate loads to continue without blocking here,
+ while higher loads get throttled by the VM.
+ */
+ if ((estimated_left<=POOL_SIZE/2)&&(!iteration))
+ page = alloc_page(GFP_NOIO);
+
if (page)
return page;
/*
@@ -338,16 +356,30 @@
current->policy |= SCHED_YIELD;
__set_current_state(TASK_RUNNING);
schedule();
+ iteration++;
goto repeat_alloc;
}
struct buffer_head *alloc_bounce_bh (void)
{
struct list_head *tmp;
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
+ int estimated_left;
+ int iteration=0;
repeat_alloc:
- bh = kmem_cache_alloc(bh_cachep, SLAB_NOIO);
+
+ spin_lock_irq(&emergency_lock);
+ estimated_left = nr_emergency_bhs;
+ spin_unlock_irq(&emergency_lock);
+
+ /* If there are plenty of spare bh's, use some of them first. If the
+ pool is at least half depleted, use the VM to allocate memory.
+ This allows moderate loads to continue without blocking here,
+ while higher loads get throttled by the VM.
+ */
+ if ((estimated_left<=POOL_SIZE/2)&&(!iteration))
+ bh = kmem_cache_alloc(bh_cachep, SLAB_NOIO);
if (bh)
return bh;
/*
@@ -376,6 +408,7 @@
current->policy |= SCHED_YIELD;
__set_current_state(TASK_RUNNING);
schedule();
+ iteration++;
goto repeat_alloc;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
reply other threads:[~2001-08-28 16:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20010828111734.A5857@devserv.devel.redhat.com \
--to=arjanv@redhat.com \
--cc=riel@nl.linux.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.