This is an archive of the discontinued LLVM Phabricator instance.

litsupport/remote: Work without shared filesystem
ClosedPublic

Authored by MatzeB on Aug 21 2018, 5:48 PM.

Details

Summary

Change litsupport/remote code to not assume a shared filesystem anymore:

  • Assumes we can run commands on the remote target and get output/returncodes back (typically ssh)
  • Expects the benchmark build directory was transfered to the remove device via other means (typically rsync) before running.

Note: This whole remote support is only relevant for apples internal usage.
At least I'm not aware of anyone else using the remote litsupport module.

I am putting this up for early review feedback. In practice we cannot
commit this yet, as lnt isn't prepared to rsync things to the device
before running (for this I actually plan to get back to other patches
of mine that allow to submit to LNT without actually running the benchmarks
via LNT itself).

Diff Detail

Event Timeline

MatzeB created this revision.Aug 21 2018, 5:48 PM
MatzeB updated this revision to Diff 162039.Aug 22 2018, 1:26 PM

Can you outline the intended workflow? My guess:

  1. cmake builddir for cross-compilation
  2. make/ninja
  3. rsync pushes test-suite builddir to target
  4. llvm-lit locale, but run every command on remote using
  5. including fpmc/VALIDATE step in *.test (SPEC2017 also uses llvm_add_host_executable)
  6. collect metrics from .o.time/.link.time files from local builddir and execution times using remote_read_result_file function.

Is this correct?

litsupport/modules/timeit.py
82–90

Did you consider keeping getUserTime with filename argument and extract-out the parsing step into a new function which can be called instead if there is not filename? There seems to be a bit of boilerplate added for every time the content is just a file (for collecting compile times).

tools/CMakeLists.txt
0–6

With the change below, this comment does not seem to apply anymore.

Can you outline the intended workflow? My guess:

  1. cmake builddir for cross-compilation
  2. make/ninja
  3. rsync pushes test-suite builddir to target
  4. llvm-lit locale, but run every command on remote using
  5. including fpmc/VALIDATE step in *.test (SPEC2017 also uses llvm_add_host_executable)

The VERIFY: steps in the scripts are run remotely as well. I hope that takes part of the spec2017 validation things[*]

  1. collect metrics from .o.time/.link.time files from local builddir and execution times using remote_read_result_file function.

Yes, things falling out of the compilation (compiletime plugin, stats plugin) is read locally, things that get produced while running a benchmark (timeit, microbenchmark modules) use context.read_result_file() which is assigned to remote_read_result_file() when running remotely (or default_read_result_file() otherwise)

Is this correct?

Yes.

  • I don't have a copy of SPEC2017 at the moment, so unfortunately I cannot actually test any of this stuff for it. We probably need some llvm_test_data() calls added to get SPEC2017 working anyway...
  1. cmake builddir for cross-compilation
  2. make/ninja
  3. rsync pushes test-suite builddir to target
  4. llvm-lit locale, but run every command on remote using ssh
  5. including fpmc/VALIDATE step in *.test (SPEC2017 also uses llvm_add_host_executable)

The VERIFY: steps in the scripts are run remotely as well.

PREPARE: and METRIC as well?

I hope that takes part of the spec2017 validation things[*]

Yes, it should. As you mentioned, it will require the reference output on the remote as well.
It also means, we don't need llvm_add_host_executable anymore, which I consider a good thing.

  1. cmake builddir for cross-compilation
  2. make/ninja
  3. rsync pushes test-suite builddir to target
  4. llvm-lit locale, but run every command on remote using ssh
  5. including fpmc/VALIDATE step in *.test (SPEC2017 also uses llvm_add_host_executable)

The VERIFY: steps in the scripts are run remotely as well.

PREPARE: and METRIC as well?

Yes PREPARE: is modified as well, and I just realized METRIC: should be modified too but is still TODO :)

I hope that takes part of the spec2017 validation things[*]

Yes, it should. As you mentioned, it will require the reference output on the remote as well.
It also means, we don't need llvm_add_host_executable anymore, which I consider a good thing.

ah indeed, that is a nice side effect.

MatzeB updated this revision to Diff 162204.Aug 23 2018, 9:31 AM
MatzeB marked 2 inline comments as done.
  • Address review comments
  • Execute METRIC: lines remotely
MatzeB updated this revision to Diff 162275.Aug 23 2018, 3:24 PM
  • Fix PGO in remote setting: We have to do the merging on the host side where the compiler toolchain resides, however before we can do that we have to retrieve the profile data from device. Make the remote module add commands to retrieve the profile data.

ping

The summary mentions this is for early review. Has this changed?

I'd love a comment/documentation somewhere about the flow between local and remote.

ping

The summary mentions this is for early review. Has this changed?

Ah yes, the first versions of this patch was not working in some corner cases like PGO. But with the latest updates I consider this patch ready.

I'd love a comment/documentation somewhere about the flow between local and remote.

I'll bring up a separate patch for the test-suite docu about running remote (which lives in the llvm repository and is confusing/out of date anyway at the moment).

ping

The summary mentions this is for early review. Has this changed?

I'd love a comment/documentation somewhere about the flow between local and remote.

Meinersbur accepted this revision.Aug 29 2018, 1:31 PM

I'll bring up a separate patch for the test-suite docu about running remote (which lives in the llvm repository and is confusing/out of date anyway at the moment).

Looking forward for the updated docs!

Overall, LGTM

This revision is now accepted and ready to land.Aug 29 2018, 1:31 PM
Meinersbur added inline comments.Aug 30 2018, 9:03 AM
tools/CMakeLists.txt
36

Notived after looking into D51465: Isn't/should timeit be executed on the remote as well?

MatzeB marked an inline comment as done.Aug 30 2018, 9:11 AM
MatzeB added inline comments.
tools/CMakeLists.txt
36

timeit-target will be executed on the remote. However on the host we still use timeit to wrap the compiler invocations for compiletime measurements.

Meinersbur added inline comments.
tools/CMakeLists.txt
36

Thanks. I forgot about the compilation times.

This revision was automatically updated to reflect the committed changes.