Message-Id: <200503291844.j2TIiqg00464@unix-os.sc.intel.com>
From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: "'Jens Axboe'" <axboe@suse.de>
Cc: "'Dave Jones'" <davej@redhat.com>, <linux-kernel@vger.kernel.org>
Subject: RE: [patch] optimization: defer bio_vec deallocation
Date: Tue, 29 Mar 2005 10:44:53 -0800
Thread-Index: AcU0NyTvIRa9PMdgQw2sXy7BjJLFGgAVTi/Q
In-Reply-To: <20050329081305.GG16636@suse.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1462
Lines: 34

> 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/