Il 11/04/2013 16:35, Michael R. Hines ha scritto: > Can I at least get a firm yes or no whether the maintainer will > accept this capability or not? > > What you ask would require defining what a "real world scenario" is,
A TPC benchmark would be a real world scenario. > and I don't think that's a good discussion to have right now. Even if we did > know the definition, I do not have the infrastructure in place to do an > exhaustive > search of such a workload. > > My personal view is: new software should define APIs, not hide APIs. Right, but introducing new APIs is not free. Let's leave is_dup_page unconditionally in now. We can always remove it later if it turns out to be useful. The important thing is to have the code in early to give it wider exposure. Once it is in, people can test it more, benchmark with/without is_dup_page, etc. We can declare it experimental, and break the protocol later if it turns out to be bad. I think all that's needed is: 1) benchmark the various chunk sizes (with is_dup_page disabled and your current stress test -- better than nothing). Please confirm that the source can modify the chunk size and the destination will just pick it up. 2) remove the patch to disable is_dup_page 3) rename the transport to "x-rdma" (just in migration.c). And that's it. The patches should be ready. We have converged on a good interface between RDMA and the generic migration code, and that's the important thing because later implementations will not throw away that work. Paolo > The capability already has a default 'true' value, which is the same behavior > that the value has always been and nobody's threatening to get rid of that. > > - Michael
