Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reducing Setting Up Target Phase? #1241

Open
hosunhc opened this issue Nov 6, 2023 · 3 comments
Open

Reducing Setting Up Target Phase? #1241

hosunhc opened this issue Nov 6, 2023 · 3 comments
Labels

Comments

@hosunhc
Copy link

hosunhc commented Nov 6, 2023

Hi, I was wondering if there is a way to reduce the amount of overhead when running WA?
I noticed that before the benchmark starts there's a "Setting up target" step, which sometimes take about 30 to 40 seconds.
Each time I run a single benchmark like 5 seconds of Dhrystone, it ultimately leads to about an overhead of 70 seconds.
Could I know where I could go into to reduce this overhead?
I've been looking through devlib and frameworks, but without much luck.
I would also like to skip the steps of compressing the cpufreq folder and pulling it from the device? As I merely just want to set the target device.
Thanks!

@marcbonnici
Copy link
Contributor

Hi,

WA will require some level of overhead as it queries the device at runtime to pull the device configuration and try to ensure that the device is in a "known" state to try and ensure repeated runs start from the same base state as much as possible.

However by default WA/devlib have a set of default modules and Augmentations that are enabled, such as cpufreq so you can try disabling these to see if this reduces the setup time.

An example agenda excerpt to do this would be something like the following and you can manually reenable any you may require for your tests.

config:
    augmentations: ['~~']              # Disable WA Augmentations
    device_config: 
        load_default_modules: false    # Disable default devlib modules
        modules: []        

Depending on how your setup is configured, another option may be to use a single WA Run to run multiple tests in a single agenda to avoid performing the overhead each time.

@douglas-raillard-arm
Copy link
Contributor

Note that some work has been done in that direction here: ARM-software/devlib#634
This PR allows devlib to lazily load (most) modules, although I think WA would still ask for some modules to be eagerly loaded by default.

@douglas-raillard-arm
Copy link
Contributor

Also, the async capabilities of devlib could allow loading multiple modules concurrently as long as they don't try to write to the same files. This is not done for now but wouldn't be very hard, as most modules only read files upon loading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants