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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 15 2001 - 21:00:16 EST