Project

General

Profile

Actions

Feature #7178

closed

Support parallel processing of sub-jobs

Added by Evgeny Novikov over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Immediate
Category:
-
Target version:
-
Start date:
05/07/2016
Due date:
% Done:

0%

Estimated time:
Published in build:
af3b58e

Description

Now sub-jobs are decided one by one primarily because of we wouldn't like to copy Linux kernel source code for each sub-job especially when we deal with the Git repository (it will take too much time and splace) while each sub-job needs a fresh source code (thus it is completely cleaned up at the beginning of each sub-job decision).

Nevertheless we do can process sub-jobs in parallel. Just source preparation (e.g. commit checkouting) and build processes of different sub-jobs should be executed strictly sequantially. As for the rest we don't need to put anything inside the source tree (yes, I already realized that it has not so much sense) and, that is much more tricky, we need to prepare true verification objects rather than just descriptions like now. That is when a build command is executed we need to copy all its input files, including headers, outside of the source tree so that we will repeat it there absolutely like the original command. It also can help to deal with very "clever" build scripts, that like remove or even worse overwrite referenced source files during build.

Technically everything looks quite simple to be implemented. Some overhead will be presented since we will need some extra time and disk space to get all referred source files, for instance when checking all modules, we will likely have to copy the most of source files.


Related issues 3 (0 open3 closed)

Related to Klever - Feature #6596: Implement more generic class JobClosedEvgeny Novikov01/29/2016

Actions
Related to Klever - Feature #6606: Process and filter raw build commands immediately after they are extractedClosedEvgeny Novikov01/29/2016

Actions
Copied from Klever - Bug #6595: Fix wating of uploading repots from other sub-jobsRejectedEvgeny Novikov01/29/2016

Actions
Actions #1

Updated by Evgeny Novikov over 8 years ago

The proposal to avoid putting anything inside source trees was implemented in branch generic-subjobs merged to master in 930b115. This BTW allowed to avoid #6595.

Users will likely not see any considerable changes, just paths in logs changed.

Developers now can find intermediate results not in the Linux kernel working source tree that was located inside klever-core-work-dir as working directories of components but inside those directories. For instance, processed build commands are put into directory lkbce, generated descriptions of verification objects are put into directory lkvog, etc. This BTW implies that the master branch should be very carefully merged to all long existing branches.

Actions #2

Updated by Evgeny Novikov over 8 years ago

  • Priority changed from High to Urgent

Recent support for testing jobs made this issue priority even higher since tests are very small and their parallel execution can very considerably speed up job decision.

Actions #3

Updated by Evgeny Novikov over 8 years ago

  • Status changed from New to Closed
  • Published in build set to 45c7ae5

Branch "parallel-subjobs" implementing this feature was merged to master in 45c7ae5.

Starting from now users can specify the number of sub-jobs to be decided in parallel like the number of threads/processes for parallel build and verification task generation. By default this number is exactly 1 for all modes since it requires very thoughtful understanding of sub-jobs nature and corresponding resource requirements. For instance, lightweight tests (e.g. for rule specifications) can be decided in parallel (each test corresponds to one sub-job) since very little resources are required for them. In contrast verification of real Linux kernel modules, in particular during validation, can require very much resources, e.g. for generating environment models. Thus one should set this number in accordance with resources available/required.

One of consequence of this feature is that now all source files referred by error traces have absolute paths that can be noticed during error trace visualization. This looks to be the only appropriate solution when we deal with very distributed files where the most of them are shadows of original source files (they are copied into LKBCE working directory and then all compilers are invoked from that directory rather than from Linux kernel working source tree), some files are original files of rule specifications, some files are generated on the basis of rule specification files. Any way during visualization just some part of these paths is shown while the whole paths can be accessible by covering those ones.

The only thing I didn't implement is automatic resolution of source files overwritten during build process. At the moment there will be an assertion and everything will fail if there will be such the case. Let's see what we will get on real modules.

Developers will see quite many changes. The most noticable ones are:
  • Neither AVTG and its plugins except RSG nor VTG and its strategies can use working source tree any more. Instead they have to use CC working directories that are presented as values of attribute cwd of CC full descriptions.
  • All processing (parsing, filtering, dumping and copying dependencies) of raw Linux kernel build commands are now performed directly when corresponding commands are executed. Before it was done in LKBCE and LKVOG. This was addressed in #6606 that I had to implement together with this feature since I needed to copy dependencies exactly when build commands were executed.
  • All files referred by C source files passed to VTG and its strategies have absolute paths. Thus everybody can relax.
  • One can introduce new locks if one will need to execute something exclusively. Unfortunately this can't be done via callbacks and thus it isn't recommended to do this except for very important cases (e.g. build processes of different sub-jobs are performed exclusively now).
Actions #4

Updated by Evgeny Novikov over 8 years ago

In addition races between build commands executed in parallel were likely fixed in 42cfbfe.

Actions #5

Updated by Evgeny Novikov over 8 years ago

  • Published in build changed from 45c7ae5 to 2e6671

Evgeny Novikov wrote:

Developers will see quite many changes. The most noticable ones are:
  • Neither AVTG and its plugins except RSG nor VTG and its strategies can use working source tree any more. Instead they have to use CC working directories that are presented as values of attribute cwd of CC full descriptions.

I changed the way how RSG receives source tree roots in f3c0e15. Before that RSG hanged forever if there more than one verification object or/and rule specification in a given (sub-)job. This change also made accessible source tree root for AVTG itself unfortunately.

Actions #6

Updated by Evgeny Novikov over 8 years ago

BTW, I forgot to mention that developers now can find in the LKBCE working directory not only build command descriptions but also all the input files of all CC build commands that can be involved in verification objects.

Actions #7

Updated by Evgeny Novikov over 8 years ago

  • Published in build changed from 2e6671 to 968abd2

One more issue was with visualization of data reports uploaded during parallel decision of sub-jobs. This was due to sub-jobs required properly shared variable to keep results obtained. The issue was fixed in 968abd2.

Besides data representation was changed considerably to make things straightforwardly rather than to apply several artificial and non-logical transformations. That's why new Bridge will not visualize old data as well as old Bridge will not visualize new data. But since just data representation was changed old data can be actually converted to the new format.

Actions #8

Updated by Evgeny Novikov over 8 years ago

  • Status changed from Closed to Open
  • Priority changed from Urgent to Immediate

Decision of validation sub-jobs in parallel revealed one more issue. It turned out that although all source files referred by CC build commands were copied to the LKBCE working directory references to them in CC build command descriptions weren't updated respectively. This caused unpleasant races that can in result in errors (missed or broken source files) in all components invoking preprocessor (SA, Weaver, ASE, ...).

The temporary workaround is to decide sub-jobs sequentially always.

Actions #9

Updated by Evgeny Novikov over 8 years ago

  • Status changed from Open to Closed
  • Published in build changed from 968abd2 to af3b58e

The issue was likely fixed in af3b58e. Besides working source trees were replaced with shadow source trees since we copy all required source files into shadow source trees while working source trees can be overwritten.

Actions

Also available in: Atom PDF