How does Coroutine Dispatchers.Default works regarding ARM big.LITTLE CPU architecture? (this came o...

# coroutines

[Daniele Segato]

How does Coroutine Dispatchers.Default works regarding ARM big.LITTLE CPU architecture? (this came out on an AndroidDev Discord server but apparently no one knew exactly how it worked)

With this architecture the "little" slow but battery efficient cores are supposed to be used when the load is low and the "big" ones kick in when needed to give more power.
I looked but couldn't find much information on what part of the OS decide when to switch between the two or how this impact user space and Android Applications.

I've even trying to look at the android example here https://ui.perfetto.dev/ but I couldn't figure out how things works I just don't have enough knowledge to read those graphs.

Coroutine Dispatchers.Default is initialized with

@JvmField
internal val CORE_POOL_SIZE = systemProp(
    "kotlinx.coroutines.scheduler.core.pool.size",
    AVAILABLE_PROCESSORS.coerceAtLeast(2),
    minValue = CoroutineScheduler.MIN_SUPPORTED_POOL_SIZE
)

and

internal val AVAILABLE_PROCESSORS = Runtime.getRuntime().availableProcessors()

does this means that the Default dispatcher contains both big and little cores? and assign work to do to each or the other just depending on the order they gets in?

Anyone has information on how this works? Do I have any control on which profile gets chosen as a developer or am I misinterpreting the all thing and the cores are swapped under the hood by the OS transparently?

Thanks in advance to whoever can help me gain a better understanding on this topic.

[phldavies]

The default dispatcher wraps a thread pool of n threads - it’s still up to the OS to schedule the execution of threads on (and possibly move between) cores. The OS could theoretically schedule all threads on a single core (fighting for resources etc) - and it may well be that this will happen on the little cores until a threshold is reached in which threads may be scheduled instead on the big cores. I couldn’t tell you exactly how the OS scheduler works here but the main point is to not conflate the threadpool size being “total cores” and actual allocation of a thread to a core.

[louiscad]

I think @romainguy is the person that knows the most about BIG.little on Android over here.

[romainguy]

The scheduler decides, and the priorities are taken into account but it has changed many times and probably keeps changing. Using native code you can set an affinity to try and stay on a given type of core but even those get reset periodically

[Daniele Segato]

Thank you for all the answers.

Does it mean that on Android (non native side) this will always be transparent?
The way I understood it: if there are 4 big cores and 4 little cores the Dispatcher.Default in coroutine will have a pool of 4 threads and the OS will switch between big/little outside my control.

Have I got it correctly? thank you.

[romainguy]

That's correct. You could a bit of JNI to set the CPU affinity though. Letting apps do more would not necessarily be a blessing I suppose because the CPU configurations can be complicated (when/how se.of the CPUs are made available, big/medium/little configurations, etc.).

[Daniele Segato]

I think the OS scheduler will be more likely to know which is the right core to use than me (an app).

Thanks, I just wanted to see if my understanding of it matched reality!

Appreciated!