[PATCH] D35598: Rework machine creation strategy

James Greenhalgh via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 11 02:00:38 PDT 2017

jgreenhalgh added a comment.

In https://reviews.llvm.org/D35598#819677, @grosser wrote:

> Hi Matze,
> I did not check the implementation in detail, but this makes total sense to me. From my perspective this is a clear improvement and should go in.

A more useful flag for our use would restore the previous behavior, rather than always update the machine. We have a lot of historical data, crossing a number of kernel versions and other machine characteristics to import to LNT. The old behavior was very convenient for this data set - we automatically ended up with new machines after each system configuration change (actually, this automatic disambiguation of machines with variations was a key benefit of LNT for us, and caught a number of bugs in our test infrastructure). We don't want to always update the machine, that would "poison" the quality of the historical data.

Inventing unique names for each of the variants would be difficult but possible. It feels like it somewhat defeats the point of the machine field - I would be re-encoding the same information in to a machine name (for example something like gcc7-cortex-a57-ubuntu-14.04-linux-4.13-64k-pages ). That makes all other interactions with the system (e.g. choosing runs for comparison)  very cumbersome.

I agree that the old behavior could be confusing, but I don't really know how to sensibly interact with the new design in a way that preserves data quality without needing an explosion in naming complexity. For me, this is not a clear improvement.



More information about the llvm-commits mailing list