On 05/08/2013 09:31 PM, Dave Martin wrote:
Hi there,
b) The inbound core will send IPI to outbound core for the synchronization, but at this point the inbound core's GIC's cpu interface is disabled; so even the core's cpu interface is disabled, can the core send SGI to other cores?
SGIs are triggered by writing to the GIC Distributor. I believe that doesn't require the triggering CPU's CPU interface to be enabled.
The destination CPU's CPU interface needs to be enabled in order for the interrupt to be received, though.
Nico can confirm whether this is correct.
I believe this does change for GICv3 though -- it may be necessary to fire up the CPU interface before an SGI can be sent in that case. This isn't an issue for v7 based platforms, but may need addressing in the future.
We will use GICv2 and Nico has confirmed that, so there should have no anymore issue.
- Now the switching is an async operation, means after the function
bL_switch_request is return back, we cannot say switching has been completed; so we have some concern for it.
I did write some patches to solve that, by providing a way for the caller to be notified of completion, while keeping the underlying mechanism asynchronous.
Nico: Can you remember whether you had any concerns about that functionality? See "ARM: bL_switcher: Add switch completion callback", posted to you on Mar 15.
I hadn't pushed for merging those at the time because I was hoping to do more testing on them, but I was diverted by other activities.
Can i get related patches?
For example, when switch from A15 core to A7 core, then maybe we want to decrease the voltage so that can save power; if the switching is an async operation, then it maybe introduce the issue is: after return back from the function bL_switch_request, then s/w will decrease the voltage; but at the meantime, the real switching is ongoing on another pair cores.
i browser the git log and get to know at the beginning the switching is synced by using kernel's workqueue, later changed to use a dedicated kernel thread with FIFO type; do u think it's better to go ahead to add sync method for switching?
Migrating from one cluster to the other has intrinsic power and time costs, caused by the time and effort needed to power CPUs up and down and migrate software and cache state across. This is more than just the time to power up a CPU.
This means that there is a limit on how rapidly it is worth switching between clusters before it leads to a net loss in terms of power and/or performance. Over shorter timescales, fine-grained CPU idling may provide better overall behaviour results.
Yes, here have two latency will contribute the time costs: 1. h/w latency: the time for the power controller to power on the core; 2. s/w latency: the outbound core save and restore contexts for VFP/NEON, GIC, generic timer and CP15 registers;
More time cost also means more power cost; and the latency will depend on the SoC's power controller implementation.
According to our profiling result on TC2, the h/w latency is long and in some situation it will take about 1ms; on the other hand, s/w latency will take about 80us; so on TC2 the migration will take more than 1ms.
My general expectation is that at reasonable switching speeds, the extra overhead of the asynchronous CPU power-on compared with a synchronous approach may not have a big impact on overall system behaviour.
Here i can think out some benefit from async approach: for example, the logical core is running on A15, there have two switching request, the first request is from A15 to A7, the second request is from A7 to A15; so if the async operation is detecting there have no change for the cluster id, then it will skip these two request.
This is the reason u guys prefer to use the async approach? If so, then maybe it also due to there have long latency for the switching on TC2 so that use the async method can get better performance?
However, it would certainly interesting to measure these effects on a faster platform. TC2 is the only hardware we had direct access to for our development work, and on that hardware the asynchronous power-up is a definite advantage.
- After enabled switcher, then it will disable hotplug.
Actually current code can support hotplug with IKS; because with IKS, the logical core will map the according physical core id and GIC's interface id, so that it can make sure if the system has hotplugged out which physical core, later the kernel can hotplug in this physical core. So could u give more hints why iks need disable hotplug?
Hotplug is possible to implement, but adds some complexity. The combination of IKS and CPUidle should allow all CPUs to be powered down automatically when not needed, so enable hotplug may not be a huge extra benefit, but that doesn't mean that functionality could not be added in the future.
Yes, we want to enable the functionality. I will explain the reason in next Nico's mail.
Cheers --Dave