I think I found where the "S" flag was put for write IO request. In the kernel function __blockdev_direct_IO(), every write request will be tagged as "sync". Since btreplay uses O_DIRECT + AIO, which should go into __blockdev_direct_IO. So now my views on btreplay: 1. for write request, btreplay will decrease merge rates, thus impact the latency etc. 2. for read request, btrecord may adjust "-max-pkts"/"-max-bunch-time" to control the size of bunch to close to the real read IO merge rates. Thx, Xuekun On Fri, Mar 5, 2010 at 3:30 PM, Xuekun Hu <xuekun.hu@xxxxxxxxx> wrote: > Updates. I decreased/increased max-pkts to 1/16, however nothing > changed, still less merges in the replay run. > > I think the "S" attribute for "write" should be the reason. First I > suspected the "S" attribute is brought by io_submit system call, > however I tested aio-stress tool which uses io_submit to send AIO > also. In the gathering traces, the write operations doesn't have "S" > attribute, however during replay, the "S" attribute happened again. > > So I wonder where the "S" comes from? Does anyone have suggestions? > Thanks in advance. > > Thx, Xuekun > -- To unsubscribe from this list: send the line "unsubscribe linux-btrace" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
