Messages in this thread Patch in this message | | | From | Neil Brown <> | Date | Thu, 12 Jul 2001 13:22:58 +1000 (EST) | Subject | Re: Is Swapping on software RAID1 possible in linux 2.4 ? |
| |
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/
| |