Messages in this thread | | | Date | Tue, 29 Mar 2005 10:13:06 +0200 | From | Jens Axboe <> | Subject | Re: [patch] optimization: defer bio_vec deallocation |
| |
On Mon, Mar 28 2005, Chen, Kenneth W wrote: > On Mon, Mar 28, 2005 at 06:38:23PM -0800, Chen, Kenneth W wrote: > > We have measured that the following patch give measurable performance gain > > for industry standard db benchmark. Comments? > > 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, could you also try running an alternative benchmark that > > you can show results from ? > > > > These nebulous claims of 'measurable gains' could mean anything. > > I'm assuming you see a substantial increase in throughput, but > > how much is it worth in exchange for complicating the code? > > Are you asking for micro-benchmark result? I had a tough time last time > around when I presented micro-benchmark result on LKML. I got kicked in > the butt for lack of evidence with performance data running real bench on > real hardware. > > I guess either way, I'm bruised one way or the other.
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'.
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?
-- 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/
| |