| nanonyme | juergbi: we have more or less completely moved to Matrix these days, that is. So we're now integrating buildbox updates. It seems clear integration commands are notoriously problematic in other builds as well | 12:54 |
|---|---|---|
| nanonyme | I'm looking at https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/3455663477: it say integrating sandbox took 50 minutes while actual build took less than a minute | 12:55 |
| nanonyme | I find it a bit odd though that integration commands are not emitted when it's stating it's integrating sandbox.... maybe there's something else than the actual integration commands happening here that is super-heavy | 12:56 |
| nanonyme | It looks like just running integration commands.... https://github.com/apache/buildstream/blob/416bdd04a03d55e387d2d777cc115a295003daa2/src/buildstream/buildelement.py#L306-L308 | 12:58 |
| nanonyme | juergbi: I'm also getting pretty sure based on code that integration batching does *not* combine multiple element commands. Instead, it combines multiple lines in *same* element into one group. So it is essentially useless because we typically only have one command | 13:06 |
| nanonyme | Well, that is definitely something to optimize then | 13:07 |
| nanonyme | I think it's for some silliness like printing labels between command groups | 13:32 |
| nanonyme | I am now experimenting with https://github.com/apache/buildstream/pull/1799 so avoid nested groups and just append commands to immediate group where possible | 14:03 |
| nanonyme | BuildStream should handle the rest in batching all commands into single invocation if there is only one group | 14:03 |
| nanonyme | That is, single sandbox run invocation | 14:04 |
| juergbi | nanonyme: that's really odd. integrating the sdl2-net.bst sandbox takes 37min in CI. here it takes 1 second, via bst shell --build components/sdl2-net.bst | 14:49 |
| juergbi | it could make sense without the FUSE capture optimization but that's in buildbox-casd 0.0.61, which is in docker images | 14:50 |
| juergbi | I see two integration commands batched but they're both from glib.bst, no other integration commands are being run. so can't confirm the batching working as expected with this | 15:00 |
| juergbi | however, something seems very wrong in the CI setup | 15:01 |
| nanonyme | juergbi: can I confirm somehow if buildbox-fuse is actually used? | 15:15 |
| *** abderrahim[m] <abderrahim[m]!abderrahim@2001:470:1af1:104:0:0:0:3558> has joined #buildstream | 15:16 | |
| abderrahim[m] | you can probably find out by looking at the buildbox-casd logs | 15:16 |
| juergbi | yes, in logs/_casd/.. there should be a line | 15:16 |
| juergbi | Using `FuseStager` as staging backend | 15:16 |
| nanonyme | 2022-12-11T13:32:18.085+0000 [164:281473435983936] [buildboxcasd_server.cpp:73] [INFO] Using FuseStager as staging backend | 15:17 |
| nanonyme | Indeed, it is using that | 15:17 |
| nanonyme | juergbi@abderrahim:gnome.org if you can think of any other things to check for, please do. I can't think of any further obvious thing | 15:35 |
| nanonyme | juergbi: something we're now doing special is usage of storage service | 15:49 |
| nanonyme | juergbi: does FUSE capture optimization have any requirements? | 16:38 |
| nanonyme | juergbi: to be honest, I suspect BuildElement should also expose no-integrate | 16:42 |
| nanonyme | So you could avoid it when you know it's not relevant | 16:42 |
| nanonyme | (it would pass through though so anyone depending on such element would get all integration commands) | 16:43 |
| nanonyme | I am concerned if there is issue with the container itself. Worst-case obviously would be nested FUSE | 17:09 |
| nanonyme | Podman should be running as root so assumably it it using proper overlay kernel filesystem | 18:50 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!