about when poky check sstate_cache #yocto

about when poky check sstate_cache #yocto

[zhangyifan46]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

I read the codes about sstate_cache. Let me briefly talk about how it work . I am not sure if it is right.
Example,we have setscene tasks A_setsscene, B_setcene.
and Task C ,D are not setscene task.
After we bitbake something, runqueue started,and it check A , B to see if the sstate_caache exists and if exist, the poky does unpacking the cache and then ,ordinary build process starts and it will skip A and B.
So checking the existence and validation of sstate_cache is before ordinary build process instead of right before execcuting A and B(for example, we have a dependency tree, A,depend on X ,checking is before X instead of between X and A)
that's the result of my reading codes. And i did a small experienment that, in the middle of a clean bitbake project, i copied  all sstae_caches to the sstate_cache directory and it seemed the bitbake skips no task and unpacking did not happen.

Finally, i have a question. Can we move the checking and unpacking to, like the example above, right before executing A ,between X and A.
it means a lot to me. Cause the sharing of sstate_cache may be helpful to a more efficent parallel make(instead of just parallel make gcc jobs)

[-- Attachment #2: Type: text/html, Size: 1238 bytes --]

Re: [poky] about when poky check sstate_cache #yocto

[Richard Purdie]

On Tue, 2020-05-26 at 23:29 -0700, zhangyifan46@huawei.com wrote:
> I read the codes about sstate_cache. Let me briefly talk about how it
> work . I am not sure if it is right.
> Example,we have setscene tasks A_setsscene, B_setcene.
> and Task C ,D are not setscene task.
> After we bitbake something, runqueue started,and it check A , B to
> see if the sstate_caache exists and if exist, the poky does unpacking
> the cache and then ,ordinary build process starts and it will skip A
> and B.
> So checking the existence and validation of sstate_cache is before
> ordinary build process instead of right before execcuting A and B(for
> example, we have a dependency tree, A,depend on X ,checking is before
> X instead of between X and A)
> that's the result of my reading codes.

This is correct. Its because if A depends on B and A is present in the
cache, we can skip B entirely in some cases. This means the checking
has to happen at the start of the build.

>  And i did a small experienment that, in the middle of a clean
> bitbake project, i copied  all sstae_caches to the sstate_cache
> directory and it seemed the bitbake skips no task and unpacking did
> not happen.

Correct.

> Finally, i have a question. Can we move the checking and unpacking
> to, like the example above, right before executing A ,between X and
> A. it means a lot to me. Cause the sharing of sstate_cache may be
> helpful to a more efficent parallel make(instead of just parallel
> make gcc jobs)

You can share the sstate cache directory amongst multiple machines over
NFS. The dependency cannot be moved just before A though for the reason
I mention above.

Cheers,

Richard

about when poky check sstate_cache #yocto

[zhangyifan46]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

I read the codes about sstate_cache. Let me briefly talk about how it work . I am not sure if it is right.
Example,we have setscene tasks A_setsscene, B_setcene.
and Task C ,D are not setscene task.
After we bitbake something, runqueue started,and it check A , B to see if the sstate_caache exists and if exist, the poky does unpacking the cache and then ,ordinary build process starts and it will skip A and B.
So checking the existence and validation of sstate_cache is before ordinary build process instead of right before execcuting A and B(for example, we have a dependency tree, A,depend on X ,checking is before X instead of between X and A)
that's the result of my reading codes. And i did a small experienment that, in the middle of a clean bitbake project, i copied  all sstae_caches to the sstate_cache directory and it seemed the bitbake skips no task and unpacking did not happen.

Finally, i have a question. Can we move the checking and unpacking to, like the example above, right before executing A ,between X and A.
it means a lot to me. Cause the sharing of sstate_cache may be helpful to a more efficent parallel make(instead of just parallel make gcc jobs)

[-- Attachment #2: Type: text/html, Size: 1223 bytes --]