>
> If you're not doing O_DIRECT, then io_getevents waits - i.e. it's synchronous.
OK. The host is indeed using a 4K block filesystem; I
couldn't find your O_DIRECT patch, but turning on O_DIRECT
with fcntl just after opening the backing file gives these
results:
http://ex-parr
On Mon, Oct 10, 2005 at 12:10:10AM -0500, Rob Landley wrote:
> Any likelihood that at some point in the future it could accidentally point
> to
> something it would be a bad idea to display?
I think the worst case is skas3 with no stack randomization, where that
page will point somewhere into th
On Sun, Oct 09, 2005 at 05:38:20PM -0500, Rob Landley wrote:
> My limiting factor is learning what they are. :)
Actually, I just took care of the rest of them.
Jeff
---
This SF.Net email is sponsored by:
Power A
arrot.com/~chris/tmp/20051010/host-vs-uml-io-results-3.png
> i.e., the AIO implementation is now slower than the stock
> implementation for writes of size up to about 8KB, but
> faster for larger writes; it's still quite a bit slower
> than the host.
There aren't very good labels o
r opening the backing file gives these
> > results:
> > http://ex-parrot.com/~chris/tmp/20051010/host-vs-uml-io-results-3.png
> > i.e., the AIO implementation is now slower than the stock
> > implementation for writes of size up to about 8KB, but
> > faster for l
On Monday 10 October 2005 09:36, Jeff Dike wrote:
> I think the worst case is skas3 with no stack randomization, where that
> page will point somewhere into the process stack. There is some slight
> possibility that something could store a password on its stack, and have
> that end up in the area
The patch to use host AIO support that I submitted early after 2.6.13 exposed
some problems in the block driver. I have fixes for these, but am not
comfortable putting them into 2.6.14 at this late date. So, this patch reverts
the use of host AIO.
I will resubmit the original patch, plus fixes
