I noticed the same thing this morning when doing some testing with multiple builds queued up. A single container build was waiting on a 4 container build to start, despite having capacity to fit it in and get started.
A common problem in managing a queue like this is ensuring that the large builds don’t get starved either. To take @sampart’s jobs from the first case (A with 3 containers, B with 1 container), if a lot of “B” jobs are getting queued up or are longer running, they can forever starve “A” jobs from starting.
Our situation is that each workflow run uses a number of 1 container jobs (e.g. setting up caches, standalone tools) and a few larger jobs that take multiple containers (e.g. test suites).
I think the best algorithm for us would be to prioritize the largest job that will fit in the open containers when something opens up, with a weight for how long something has been sitting in the queue to override it if needed.
I’d love the small jobs just to fill in the nooks and crannies that the larger jobs leave behind, vs. just having them delayed (and affecting items queued further beyond them).