[lkml]   [2001]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: Is Swapping on software RAID1 possible in linux 2.4 ?
On Thursday July 12, 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

--- 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 @@
} 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
instead of
kmalloc(sizeof(struct buffer_head), GFP_whatever)
but I hadn't 'got' the slab stuff properly when I was writing that

Peter, does the above little patch help your problem?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.081 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site