Messages in this thread | | | From | "Chen, Kenneth W" <> | Subject | RE: [patch] optimization: defer bio_vec deallocation | Date | Tue, 29 Mar 2005 10:44:53 -0800 |
| |
> Dave Jones wrote on Monday, March 28, 2005 7:00 PM > > If you can't publish results from that certain benchmark due its stupid > > restrictions,
Forgot to thank Dave earlier for his understanding. I can't even mention the 4 letter acronym for the benchmark. Sorry, I did not make the rule nor have the power to change the rule.
Jens Axboe wrote on Tuesday, March 29, 2005 12:13 AM > Just _some_ results would be nice, Dave is right in that 'measurable > gains' doesn't really say anything at all. Personally I would like to > see a profile diff, for instance. And at least something like 'we get 1% > gain bla bla'.
OK, performance gain for this industry db benchmark is 0.3%.
> Now, about the patch. I cannot convince myself that it is not deadlock > prone, if someone waits for a bvec to be freed. Will slab reclaim always > prune the bio slab and push the bvecs back into the mempool, or can > there be cases where this doesn't happen?
So on allocation, I should always get memory from slab first, if fail then get from mempool. Mark the bvec appropriately where the memory came from. On deallocating bio, check bvec flag and return memory if they came from mempool. Would that address your concern?
- 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/
| |