2.4.18-pre8 + 2.4.17-pre8-ac3 + rmap12c + XFS Results

2.4.18-pre8 + 2.4.17-pre8-ac3 + rmap12c + XFS Results

[Shawn Starr]

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
is able to handle heavy heavy memory usage (mozilla + evolution +
blowup-xfs - fsx-linux.c to test XFS's stability with VM).

Also, XFS so far is preforming without file corruption that I can see.

a patch will be available for this shortly on my website for those who
want XFS + rmap12c.

Shawn.

Re: 2.4.18-pre8 + 2.4.17-pre8-ac3 + rmap12c + XFS Results

[Shawn]

Is that http://www.sh0n.net/~spstarr/ ?

On 02/06, Shawn Starr said something like:
> a patch will be available for this shortly on my website for those who
> want XFS + rmap12c.
> 
> Shawn.
--
Shawn Leas
core@enodev.com

I installed a skylight in my apartment...
The people who live above me are furious!
						-- Stephen Wright

Re: 2.4.18-pre8 + 2.4.18-pre7-ac3 + rmap12c + XFS Results

[Shawn Starr]

a mirror site has sprung up it will be on xfs.sh0n.net when the site is up
later today. I'll update the list with that info after.

On Wed, 6 Feb 2002, Shawn wrote:

> Is that http://www.sh0n.net/~spstarr/ ?
>
> On 02/06, Shawn Starr said something like:
> > a patch will be available for this shortly on my website for those who
> > want XFS + rmap12c.
> >
> > Shawn.
> --
> Shawn Leas
> core@enodev.com
>
> I installed a skylight in my apartment...
> The people who live above me are furious!
> 						-- Stephen Wright
>
>

Re: 2.4.18-pre8 + 2.4.17-pre8-ac3 + rmap12c + XFS Results

[Dan Chen]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

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

-- 
Dan Chen                 crimsun@email.unc.edu
GPG key:   www.unc.edu/~crimsun/pubkey.gpg.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.18-pre8 + 2.4.17-pre8-ac3 + rmap12c + XFS Results

[William Lee Irwin III]

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

Re: 2.4.18-pre8 + 2.4.17-pre8-ac3 + rmap12c + XFS Results

[Shawn Starr]

Yes, I'll apply this diff to my tree when I get home today. 

On Wed, 2002-02-06 at 04:13, Dan Chen wrote:
> 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
>                                     ^^^^^^^^^^^^^^^^^^^^
> 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.
> 
> -- 
> Dan Chen                 crimsun@email.unc.edu
> GPG key:   www.unc.edu/~crimsun/pubkey.gpg.asc