Excerpts from Tejun Heo's message of 2011-03-23 06:46:14 -0400:
> Hello, Chris.
>
> On Tue, Mar 22, 2011 at 07:13:09PM -0400, Chris Mason wrote:
> > Ok, this impact of this is really interesting. If we have very short
> > waits where there is no IO at all, this patch tends to lose. I ran with
>
Hello, Chris.
On Tue, Mar 22, 2011 at 07:13:09PM -0400, Chris Mason wrote:
> Ok, this impact of this is really interesting. If we have very short
> waits where there is no IO at all, this patch tends to lose. I ran with
> dbench 10 and got about 20% slower tput.
>
> But, if we do any IO at all
Excerpts from Tejun Heo's message of 2011-03-21 14:11:24 -0400:
> Hello,
>
> On Mon, Mar 21, 2011 at 01:24:37PM -0400, Chris Mason wrote:
> > Very interesting. Ok, I'll definitely rerun my benchmarks as well. I
> > used dbench extensively during the initial tuning, but you're forcing
> > the mem
Hello,
On Mon, Mar 21, 2011 at 01:24:37PM -0400, Chris Mason wrote:
> Very interesting. Ok, I'll definitely rerun my benchmarks as well. I
> used dbench extensively during the initial tuning, but you're forcing
> the memory low in order to force IO.
>
> This case doesn't really hammer on the lo
Excerpts from Tejun Heo's message of 2011-03-21 12:59:55 -0400:
> Hello,
>
> Here are the results with voluntary preemption. I've moved to a
> beefier machine for testing. It's dual Opteron 2347, so dual socket,
> eight core. The memory is limited to 1GiB to force IOs and the disk
> is the same
On Mon, Mar 21, 2011 at 05:59:55PM +0100, Tejun Heo wrote:
> I'm running DFL again just in case but SIMPLE or SPIN seems to be a
> much better choice.
Got 644.176 MB/sec, so yeah the custom locking is definitely worse
than just using mutex.
Thanks.
--
tejun
--
To unsubscribe from this list: sen
Hello,
Here are the results with voluntary preemption. I've moved to a
beefier machine for testing. It's dual Opteron 2347, so dual socket,
eight core. The memory is limited to 1GiB to force IOs and the disk
is the same OCZ Vertex 60gig SSD. /proc/stat is captured before and
after "dbench 50".
Hello, Chris.
On Sun, Mar 20, 2011 at 08:10:51PM -0400, Chris Mason wrote:
> I went through a number of benchmarks with the explicit
> blocking/spinning code and back then it was still significantly faster
> than the adaptive spin. But, it is definitely worth doing these again,
> how many dbench
Excerpts from Tejun Heo's message of 2011-03-20 13:44:33 -0400:
> Hello, guys.
>
> I've been looking through btrfs code and found out that the locking
> was quite interesting. The distinction between blocking and
> non-blocking locking is valid but is essentially attacing the same
> problem that
On Sun, Mar 20, 2011 at 08:56:52PM +0100, Tejun Heo wrote:
> So, here's the patch to implement and use mutex_try_spin(), which
> applies the same owner spin logic to try locking. The result looks
> pretty good.
>
> I re-ran all three. DFL is the current custom locking. SIMPLE is
> with only the
So, here's the patch to implement and use mutex_try_spin(), which
applies the same owner spin logic to try locking. The result looks
pretty good.
I re-ran all three. DFL is the current custom locking. SIMPLE is
with only the previous patch applied. SPIN is both the previous and
this patches ap
Hello, guys.
I've been looking through btrfs code and found out that the locking
was quite interesting. The distinction between blocking and
non-blocking locking is valid but is essentially attacing the same
problem that CONFIG_MUTEX_SPIN_ON_OWNER addresses in generic manner.
It seemed that CONF
12 matches
Mail list logo
