[patch] optimization: defer bio_vec deallocation

[Dave Jones]

We have measured that the following patch give measurable performance gain
for industry standard db benchmark. Comments?

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?

Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Chen, Kenneth W]

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Jens Axboe]

Post by Chen, Kenneth W

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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Chen, Kenneth W]

Post by Chen, Kenneth W
Dave Jones wrote on Monday, March 28, 2005 7:00 PM

Post by Dave Jones
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

Post by Chen, Kenneth W
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%.

Post by Chen, Kenneth W
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Dave Jones]

Post by Chen, Kenneth W

Post by Chen, Kenneth W
Dave Jones wrote on Monday, March 28, 2005 7:00 PM

Post by Dave Jones
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.

That's ok, I substituted its name for some four letter words of my own. :)

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Andrew Morton]

Post by Chen, Kenneth W

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?

There are a number of test tools floating about. reaim, orasim, osdb, others.

A number of them are fairly crufty and toy-like, but still more useful than
microbenchmarks, and they permit others to evaluate patches and to perform
further optimisation.

It's in everyone's interest that we get away from a test which has such
dopey restrictions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------