Messages in this thread | | | Date | Wed, 30 Mar 2005 12:30:22 +0200 | From | Jens Axboe <> | Subject | Re: [patch] optimization: defer bio_vec deallocation |
| |
On Tue, Mar 29 2005, Chen, Kenneth W wrote: > 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%.
OK.
> > 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?
Hmmm no, I don't think we are talking about the same thing (what you describe is what currently happens anyways, this is how mempools work). Am I guarenteed to get a bio with a bvec already assigned when doing a bio allocation, if one exists?
-- Jens Axboe
- 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/
| |