Re: raid 5 read performance
On Saturday October 21, [EMAIL PROTECTED] wrote: On Sun, 21 May 2006, Neil Brown wrote: Please read http://www.spinics.net/lists/raid/msg11838.html and ask if you have further questions. Neil, what is the current status on the slow read performance with 2.6 ? You mean by-passing the cache to avoid extra copy and synchronisation overheads? I have the patches. I tried them once and couldn't measure any speedup (I didn't try very hard) and put them aside think I have to look into this properly and haven't got back to it yet. Thanks for the reminder. Hope to do some performance measurements soon. I'll make sure I include these patches when I do. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raid 5 read performance
On Sun, 21 May 2006, Neil Brown wrote: Please read http://www.spinics.net/lists/raid/msg11838.html and ask if you have further questions. Neil, what is the current status on the slow read performance with 2.6 ? Regards, Stephan - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raid 5 read performance
On 8/5/06, Raz Ben-Jehuda(caro) [EMAIL PROTECTED] wrote: patch is applied by Neil. I do not know when he going to apply it. i have applied it on my systems ( on 2.6.15 ) but they are currenly in the lab and not in production. Raz. PS I must say that it saves lots of cpu cycles. Did you send the 2.6.15 patch in a private message I can't find it in the archives? Thanks, Dan - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
raid 5 read performance
Neil hello Sorry for the delay. too many things to do. I have implemented all said in : http://www.spinics.net/lists/raid/msg11838.html As always I have some questions: 1. mergeable_bvec I did not understand first i must admit. now i do not see how it differs from the one of raid0. so i actually copied it and renamed it. 2. statistics. i have added md statistics since the code does not reach the statics in make_request. it returns from make_request before that. 3. i have added the new retry list called toread_aligned to raid5_conf_t . hope this is correct. 4. your instructions are to add a failed bio to sh, but it does not say to handle it directly. i have tried it and something is missing here. raid5d handle stripes only if conf-handle_list is not empty. i added handle_stripe and and release_stripe of my own. this way i managed to get from the completion routine: R5: read error corrected!! message . ( i have tested by failing a ram disk ). 5. I am going to test the non common path heavily before submitting you the patch ( on real disks and use several file systems and several chunk sizes). It is quite a big patch so I need to know which kernel do you want me to use ? i am using poor 2.6.15. I thank you -- Raz - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raid 5 read performance
On Friday June 9, [EMAIL PROTECTED] wrote: Neil hello Sorry for the delay. too many things to do. You aren't alone there! I have implemented all said in : http://www.spinics.net/lists/raid/msg11838.html As always I have some questions: 1. mergeable_bvec I did not understand first i must admit. now i do not see how it differs from the one of raid0. so i actually copied it and renamed it. Sounds fine. For raid5 there is no need to force write requests to be split up, but that's a minor difference. 2. statistics. i have added md statistics since the code does not reach the statics in make_request. it returns from make_request before that. Why not put the code *after* that? Not that it matters a great deal. I'll comment more when I see the code I expect. 3. i have added the new retry list called toread_aligned to raid5_conf_t . hope this is correct. Sounds good. 4. your instructions are to add a failed bio to sh, but it does not say to handle it directly. i have tried it and something is missing here. raid5d handle stripes only if conf-handle_list is not empty. i added handle_stripe and and release_stripe of my own. this way i managed to get from the completion routine: R5: read error corrected!! message . ( i have tested by failing a ram disk ). Sounds right, but I'd need to see the code to be sure. 5. I am going to test the non common path heavily before submitting you the patch ( on real disks and use several file systems and several chunk sizes). I'd rather see the patch earlier, even if it isn't fully tested. It is quite a big patch so I need to know which kernel do you want me to use ? i am using poor 2.6.15. A patch against the latest -mm would be best, but I'm happy to take it against anything even vaguely recent. However, it needs to be multiple patches, not just one. This is a *very* important point. As that original email said: This should be developed and eventually presented as a sequence of patches. There are several distinct steps in this change and they need to be reviewed separately or it is just too hard. So I would really like it if you could separate out the changes into logically distinct patches. If you can't or won't, then still send the patch, but I'll have to break it up so it'll probably take longer to process. Thanks for your efforts, NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
raid 5 read performance
Neil hello
I am measuring read performance of two raid5 with 7 sata disks, chunk size 1MB.
when i set the stripe_cache_size to 4096 i get 240 MB/s. IO'ing from
the two raids ended with 270 MB/s.
i have added a code in make_request which passes the raid5 logic in
the case of read.
it looks like this :
static int make_request (request_queue_t *q, struct bio * bi)
{
.
if ( conf-raid5_bypass_readbio_data_dir(bi) == READ )
{
new_sector = raid5_compute_sector(bi-bi_sector,
raid_disks,
data_disks,
dd_idx,
pd_idx,
conf);
bi-bi_sector = new_sector;
bi-bi_bdev = conf-disks[dd_idx].rdev-bdev;
//
// do some statics
//
disk_stat_inc(mddev-gendisk, ios[rw]);
disk_stat_add(mddev-gendisk, sectors[rw], bio_sectors(bi));
//
// make upper level to the work for me
//
return 1;
}
...
}
it increased the performance to 440 MB/s.
Question :
What is the cost of not walking trough the raid5 code in the
case of READ ?
if i add and error handling code will it be suffice ?
thank you
--
Raz
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raid 5 read performance
On Sunday May 21, [EMAIL PROTECTED] wrote: Question : What is the cost of not walking trough the raid5 code in the case of READ ? if i add and error handling code will it be suffice ? Please read http://www.spinics.net/lists/raid/msg11838.html and ask if you have further questions. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raid 5 read performance
Please read http://www.spinics.net/lists/raid/msg11838.html and ask if you have further questions. Does this implementation also need to do delayed updates to the stripe cache? I.e. we bypass the cache and get the requester the data it needs but then schedule that data to also be copied into the cache by the work queue. The thinking being to reduce the read penalties associated with subsequent writes to the stripe. Dan - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
