Chris Mason wrote on Friday, December 01, 2006 7:37 AM
> > It benefit from shorter path length. It takes much shorter time to process
> > one I/O request, both in the submit and completion path. I always think in
> > terms of how many instructions, or clock ticks does it take to convert user
> >
On Nov 30, 2006, at 10:16 PM, Chen, Kenneth W wrote:
Zach Brown wrote on Thursday, November 30, 2006 1:45 PM
At that time, a patch was written for raw device to demonstrate that
large performance head room is achievable (at ~20% speedup for
micro-
benchmark and ~2% for db transaction
On Thu, Nov 30, 2006 at 10:16:53PM -0800, Chen, Kenneth W wrote:
> Zach Brown wrote on Thursday, November 30, 2006 1:45 PM
> > > At that time, a patch was written for raw device to demonstrate that
> > > large performance head room is achievable (at ~20% speedup for micro-
> > > benchmark and ~2%
On Thu, Nov 30, 2006 at 10:16:53PM -0800, Chen, Kenneth W wrote:
Zach Brown wrote on Thursday, November 30, 2006 1:45 PM
At that time, a patch was written for raw device to demonstrate that
large performance head room is achievable (at ~20% speedup for micro-
benchmark and ~2% for db
On Nov 30, 2006, at 10:16 PM, Chen, Kenneth W wrote:
Zach Brown wrote on Thursday, November 30, 2006 1:45 PM
At that time, a patch was written for raw device to demonstrate that
large performance head room is achievable (at ~20% speedup for
micro-
benchmark and ~2% for db transaction
Chris Mason wrote on Friday, December 01, 2006 7:37 AM
It benefit from shorter path length. It takes much shorter time to process
one I/O request, both in the submit and completion path. I always think in
terms of how many instructions, or clock ticks does it take to convert user
request
Zach Brown wrote on Thursday, November 30, 2006 1:45 PM
> > At that time, a patch was written for raw device to demonstrate that
> > large performance head room is achievable (at ~20% speedup for micro-
> > benchmark and ~2% for db transaction processing benchmark) with a
> > tight I/O
At that time, a patch was written for raw device to demonstrate that
large performance head room is achievable (at ~20% speedup for micro-
benchmark and ~2% for db transaction processing benchmark) with a
tight
I/O submission processing loop.
Where exactly does the benefit come from? icache
At that time, a patch was written for raw device to demonstrate that
large performance head room is achievable (at ~20% speedup for micro-
benchmark and ~2% for db transaction processing benchmark) with a
tight
I/O submission processing loop.
Where exactly does the benefit come from? icache
Zach Brown wrote on Thursday, November 30, 2006 1:45 PM
At that time, a patch was written for raw device to demonstrate that
large performance head room is achievable (at ~20% speedup for micro-
benchmark and ~2% for db transaction processing benchmark) with a
tight I/O submission
I've been complaining about O_DIRECT I/O processing being exceedingly
complex and slow since March 2005, see posting below:
http://marc.theaimsgroup.com/?l=linux-kernel=111033309732261=2
At that time, a patch was written for raw device to demonstrate that
large performance head room is achievable
I've been complaining about O_DIRECT I/O processing being exceedingly
complex and slow since March 2005, see posting below:
http://marc.theaimsgroup.com/?l=linux-kernelm=111033309732261w=2
At that time, a patch was written for raw device to demonstrate that
large performance head room is
12 matches
Mail list logo
