On Thu, May 15, 2008 at 4:24 AM, Chris Webb <[EMAIL PROTECTED]> wrote: > Since you mention trying socketfilter, I've attached a newer version of my > socketfilter patch which I've recently sent to Ed. This is functionally the > same as the earlier one against vblade-15, but pulls out the BPF code from > linux.c and freebsd.c into a single bpf.c and loses the dependency on > libpcap headers, as he requested. As far as I can tell, with this patch > applied, a collection of vblades should perform identically to qaoed but > with less complex code. (If any performance gap remains, I'd like to know so > I can fix it!) >
I'll email you off line when I have time (probably in 2 weeks) to work on providing validation of a test case for this. > I've also attached a second patch which applies on top of the socketfilter > patch and adds a number of options to vblade. In particular, -d for > O_DIRECT, -s for O_SYNC, -r for read-only export and (now) -b for altering > the advertised buffer count as you describe. I use this patch locally and it > sounds like you might find it useful too. > Thanks! We'll be testing this along with the socketfilter patch. This is much cleaner than what we are doing now. > I've tested this modified vblade fairly carefully both on Linux and FreeBSD > 7.0 and can confirm it compiles without warnings and runs fine on both > supported platforms. > > When it comes to the AIO support I wrote, I found surprisingly little > performance benefit from it despite the underlying block devices being much > slower than the network. However, I'm linking against a userspace AIO > implementation (in librt) rather than using kernel AIO support, and you are > using much higher-end hardware than I have here. I would be very interested > in any feedback you have from testing in your environment, especially if you > try it with a kernel-backed AIO implementation. > It's not so much a performance benefit, it's a "make sure the data is written to disk when non-AIO requests come in" thing. With AIO support, we ought to be able to ensure that to a higher level. > Best wishes, > > Chris. > Thanks, Justin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Aoetools-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
