On Thu, Nov 12, 2020 at 10:19 AM Peter Xu <peterx@xxxxxxxxxx> wrote: > > On Wed, Nov 11, 2020 at 01:26:27PM +0100, Andrew Jones wrote: > > Nothing sets USE_CLEAR_DIRTY_LOG anymore, so anything it surrounds > > is dead code. > > > > Reviewed-by: Ben Gardon <bgardon@xxxxxxxxxx> > > Signed-off-by: Andrew Jones <drjones@xxxxxxxxxx> > > It's kind of a pity that there seem to a few valid measurements for clear dirty > log from Ben. I'm just thinking whether clear dirty log should be even more > important since imho that should be the right way to use KVM_GET_DIRTY_LOG on a > kernel new enough, since it's a total win (not like dirty ring, which depends). I didn't review this patch closely enough, and assumed the clear dirty log was still being done because of afdb19600719 KVM: selftests: Use a single binary for dirty/clear log test Looking back now, I see that that is not the case. I'd like to retract my endorsement in that case. I'd prefer to leave the dead code in and I'll send another series to actually use it once this series is merged. I've already written the code to use it and time the clearing, so it seems a pity to remove it now. Alternatively I could just revert this commit in that future series, though I suspect not removing the dead code would reduce the chances of merge conflicts. Either way works. I can extend the dirty log mode functions from dirty_log_test for dirty_log_perf_test in that series too. > > So far, the statement is definitely true above, since we can always work on > top. So: > > Reviewed-by: Peter Xu <peterx@xxxxxxxxxx> > > Thanks, > > -- > Peter Xu >
