On Dec 15, 2006 10:49 -0500, Jody McIntyre wrote: > > > One interesting result is that smaller chunk sizes than we currently > > > recommend can increase read performance by allowing larger request > > > sizes. I'm not sure why it is possible to do a 2 or 4MB request > > > through the MD layer with 128K chunks but not with 256K chunks. No > > > error is shown on the console in the failing case. > > One thought I had on the smaller chunk size is that perhaps 128K IOs end > up being merged by Alex's raid5-merge-ios.patch so the disks actually > see larger IOs and therefore perform well. Alex, is this possible? Do > you have any other theories on why smaller chunk sizes than we recommend > actually produce better performance?
To be honest, if smaller chunk sizes perform better than that is the best of both worlds. It means that smaller IOs will have to do less or smaller read-modify-write operations on the RAID5 parity. > It's x86_64, so 4KB. I don't think scatter/gather descriptors come into > play at this point since the 4MB write will be broken up into smaller > writes by the MD layer. Hmm, though wouldn't the incoming request itself have to be put into an bio in order to be submitted? There are patches in bug 9945 that Bull has been testing in this area. > > By default, the maximum request size issued by clients is 1MByte which > > is the LNET MTU. It's possible to build lustre with a larger maximum > > I/O size that can be exploited in special cases (e.g. no routing, page > > size on client and server > 4K and the LND supports it). Supporting these > > in the general case requires changes in lustre (e.g. multiple bulk > > transfers in a single RPC). > > What about echo clients talking directly to a local obdfilter? That is > what I am attempting to survey. I realize Lustre in general does not > support IOs larger than 1MB; part of the point of my current work is to > see if 4 MB IOs are something we need to support in more general cases. You would need to compile Lustre with an LNET_MTU of 4MB (to get the same sized PTLRPC_MAX_BRW_SIZE) so that the filter allocates a large enough pool for the iobuf. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. _______________________________________________ Lustre-devel mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-devel
