Liran Schour wrote: > jan.kis...@web.de wrote on 25/11/2009 00:55:57: > > >> trying to understand the code and fixing some cosmetic issues around >> progress reporting, one potentially performance-relevant question popped > up: >> lir...@il.ibm.com wrote: >>> diff --git a/block-migration.c b/block-migration.c >>> new file mode 100644 >>> index 0000000..4b4eddf >>> --- /dev/null >>> +++ b/block-migration.c >> ... >> >>> +static int mig_read_device_bulk(QEMUFile *f, BlkMigDevState *bms) >>> +{ >>> + int nr_sectors; >>> + int64_t total_sectors, cur_sector = 0; >>> + BlockDriverState *bs = bms->bs; >>> + BlkMigBlock *blk; >>> + >>> + blk = qemu_malloc(sizeof(BlkMigBlock)); >>> + blk->buf = qemu_malloc(BLOCK_SIZE); >>> + >>> + cur_sector = bms->cur_sector; >>> + total_sectors = bdrv_getlength(bs) >> SECTOR_BITS; >> Why re-calculating total_sectors here? Specifically bdrv_getlength() can >> be a non-trivial I/O operation. >> >> And what is the difference to bms->total_sectors which looks a lot > like... >> [...] >>> + >>> +static void init_blk_migration(QEMUFile *f) >>> +{ >>> + BlkMigDevState **pbmds, *bmds; >>> + BlockDriverState *bs; >>> + >>> + for (bs = bdrv_first; bs != NULL; bs = bs->next) { >>> + if(bs->type == BDRV_TYPE_HD) { >>> + bmds = qemu_mallocz(sizeof(BlkMigDevState)); >>> + bmds->bs = bs; >>> + bmds->bulk_completed = 0; >>> + bmds->total_sectors = bdrv_getlength(bs) >> SECTOR_BITS; >> ...it already contains all the information we need? >> > > You are right no need to figure it out once again. We can use the old > total_sectors value.
Perfect. Meanwhile I've quite a few patches here, including that change, will hopefully manage to send them out today. Jan
signature.asc
Description: OpenPGP digital signature