All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Dan Chen <crimsun@email.unc.edu>
Cc: Shawn Starr <spstarr@sh0n.net>,
	linux-kernel@vger.kernel.org, riel@surriel.com
Subject: Re: 2.4.18-pre8 + 2.4.17-pre8-ac3 + rmap12c + XFS Results
Date: Wed, 6 Feb 2002 05:07:41 -0800	[thread overview]
Message-ID: <20020206130741.GA767@holomorphy.com> (raw)
In-Reply-To: <Pine.LNX.4.40.0202060213380.395-100000@coredump.sh0n.net> <20020206091338.GA670@opeth.ath.cx>
In-Reply-To: <20020206091338.GA670@opeth.ath.cx>

On Wed, Feb 06, 2002 at 02:17:28AM -0500, Shawn Starr wrote:
>> I'm happy to say that rmap12c has huge preformance improvements over
>> rmap11c with my Pentium 200Mhz w/64MB ram.
>> Some of the differences:
>> rmap11c: slow redrawing of mozilla, mouse hangs, system sluggishness.
>> rmap12c: no slow redrawing UNLESS heavy I/O & swapping is occuring. System
>                                     ^^^^^^^^^^^^^^^^^^^^

On Wed, Feb 06, 2002 at 04:13:38AM -0500, Dan Chen wrote:
> Would you try the ChangeSet 1.188, specifically the one for
> fs/buffer.c@1.52?
> http://linuxvm.bkbits.net:8088/vm-2.4/diffs/fs/buffer.c@1.52?nav=index.html|ChangeSet@-2d|cset@1.188
> 
> I agree that rmap12c + the above fix has noticeable improvements over
> the 11 series. I'll be pushing some numbers out later today.

That patch is:

--- 1.51/fs/buffer.c	Wed Jan 23 15:29:44 2002
+++ 1.52/fs/buffer.c	Mon Feb  4 05:08:59 2002
@@ -2933,7 +2933,6 @@
 
 		spin_lock(&lru_list_lock);
 		if (!write_some_buffers(NODEV) || balance_dirty_state() < 0) {
-			wait_for_some_buffers(NODEV);
 			interruptible_sleep_on(&bdflush_wait);
 		}
 	}
@@ -2964,7 +2964,6 @@
 	complete((struct completion *)startup);
 
 	for (;;) {
-		wait_for_some_buffers(NODEV);
 
 		/* update interval */
 		interval = bdf_prm.b_un.interval;

I think I already sent him that, along with the following, which updates
rmap to akpm's read-latency-2.

Cheers,
Bill


diff -urN linux-virgin/drivers/block/elevator.c linux-wli/drivers/block/elevator.c
--- linux-virgin/drivers/block/elevator.c	Mon Feb  4 17:12:08 2002
+++ linux-wli/drivers/block/elevator.c	Tue Feb  5 17:31:24 2002
@@ -80,31 +80,38 @@
 			 struct buffer_head *bh, int rw,
 			 int max_sectors)
 {
-	struct list_head *entry = &q->queue_head;
-	unsigned int count = bh->b_size >> 9, ret = ELEVATOR_NO_MERGE;
+	struct list_head *entry;
+	unsigned int count = bh->b_size >> 9;
+	unsigned int ret = ELEVATOR_NO_MERGE;
+	int merge_only = 0;
 	const int max_bomb_segments = q->elevator.max_bomb_segments;
-
+ 
+	entry = &q->queue_head;
 	while ((entry = entry->prev) != head) {
 		struct request *__rq = blkdev_entry_to_request(entry);
 
-		/*
-		 * simply "aging" of requests in queue
-		 */
-		if (__rq->elevator_sequence-- <= 0)
-			break;
-
+		if (__rq->elevator_sequence-- <= 0) {
+			/*
+			 * OK, we've exceeded someone's latency limit.
+			 * But we still continue to look for merges,
+			 * because they're so much better than seeks.
+			 */
+			merge_only = 1;
+		}
 		if (__rq->waiting)
 			continue;
 		if (__rq->rq_dev != bh->b_rdev)
 			continue;
-		if (!*req && bh_rq_in_between(bh, __rq, &q->queue_head))
+		if (!*req && !merge_only &&
+			bh_rq_in_between(bh, __rq, &q->queue_head)) {
 			*req = __rq;
+		}
 		if (__rq->cmd != rw)
 			continue;
 		if (__rq->nr_sectors + count > max_sectors)
 			continue;
 		if (__rq->elevator_sequence < count)
-			break;
+			merge_only = 1;
 		if (__rq->sector + __rq->nr_sectors == bh->b_rsector) {
 			ret = ELEVATOR_BACK_MERGE;
 			*req = __rq;
diff -urN linux-virgin/drivers/block/ll_rw_blk.c linux-wli/drivers/block/ll_rw_blk.c
--- linux-virgin/drivers/block/ll_rw_blk.c	Mon Feb  4 17:11:27 2002
+++ linux-wli/drivers/block/ll_rw_blk.c	Tue Feb  5 17:31:24 2002
@@ -1095,7 +1095,7 @@
 int __init blk_dev_init(void)
 {
 	struct blk_dev_struct *dev;
-	int total_ram;
+	int total_ram;		/* kilobytes */
 
 	request_cachep = kmem_cache_create("blkdev_requests",
 					   sizeof(struct request),
@@ -1117,9 +1117,11 @@
 	 * Free request slots per queue.
 	 * (Half for reads, half for writes)
 	 */
-	queue_nr_requests = 64;
-	if (total_ram > MB(32))
-		queue_nr_requests = 128;
+	queue_nr_requests = (total_ram >> 9) & ~15;	/* One per half-megabyte */
+	if (queue_nr_requests < 32)
+		queue_nr_requests = 32;
+	if (queue_nr_requests > 1024)
+		queue_nr_requests = 1024;
 
 	/*
 	 * Batch frees according to queue length

  reply	other threads:[~2002-02-06 13:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-06  7:17 2.4.18-pre8 + 2.4.17-pre8-ac3 + rmap12c + XFS Results Shawn Starr
2002-02-06  8:23 ` Shawn
2002-02-06  8:50   ` 2.4.18-pre8 + 2.4.18-pre7-ac3 " Shawn Starr
2002-02-06  9:13 ` 2.4.18-pre8 + 2.4.17-pre8-ac3 " Dan Chen
2002-02-06 13:07   ` William Lee Irwin III [this message]
2002-02-06 15:26   ` Shawn Starr

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=20020206130741.GA767@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=crimsun@email.unc.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@surriel.com \
    --cc=spstarr@sh0n.net \
    /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.