Re: Is Swapping on software RAID1 possible in linux 2.4 ?

[Neil Brown <neilb@cse.unsw.edu.au>]

On Thursday July 12, andrewm@uow.edu.au wrote:
> 
> Could you please review these changes?

I think I see what you are trying to do, and there is nothing
obviously wrong except this comment :-)

> + * Return true if the caller make take a raid1_bh from the list.
                                ^^^^

but now that I see what the problem is, I think a simpler patch would
be 

--- drivers/md/raid1.c	2001/07/12 02:00:35	1.1
+++ drivers/md/raid1.c	2001/07/12 02:01:42
@@ -83,6 +83,7 @@
 			cnt--;
 		} else {
 			PRINTK("raid1: waiting for %d bh\n", cnt);
+			run_task_queue(&tq_disk);
 			wait_event(conf->wait_buffer, conf->freebh_cnt >= cnt);
 		}
 	}
@@ -170,6 +171,7 @@
 			memset(r1_bh, 0, sizeof(*r1_bh));
 			return r1_bh;
 		}
+		run_task_queue(&tq_disk);
 		wait_event(conf->wait_buffer, conf->freer1);
 	} while (1);
 }


This is needed anyway to be "correct", as you should always unplug
the queues before waiting for IO to complete.

On the issue of whether to pre-allocate some reserved structures or
not, I think it's "6-of-one-half-a-dozen-of-the-other".  My rationale
for pre-allocating was that the buffer that we hold on to would have
been allocated together and so probably are fairly dense within their
pages, and so there is no risk of hogging excess memory that isn't
actually being used.  Mind you, if I was really serious about being
gentle on the memory allocation, I would use 
   kmem_cache_alloc(bh_cachep,SLAB_whatever)
instead of 
   kmalloc(sizeof(struct buffer_head), GFP_whatever)
but I hadn't 'got' the slab stuff properly when I was writing that
code. 

Peter, does the above little patch help your problem?

NeilBrown