[Cbe-oss-dev] [PATCH 17/28]MARS/base: cache workload context

[Yuji Mano]

Kazunori Asayama wrote:
> I suppose the 'WORKLOAD_KERNEL_ID' should be reset when a workload is
> scheduled (i.e. when the workload transits to SCHEDULING state) since
> workload IDs can be reused and cached context is no longer valid.

--- a/base/src/host/lib/workload_queue.c
+++ b/base/src/host/lib/workload_queue.c
@@ -256,6 +256,8 @@ static int alloc_block(uint64_t block_ea
 		    MARS_WORKLOAD_STATE_NONE) {
 			MARS_BITS_SET(&bits, WORKLOAD_STATE,
 				      MARS_WORKLOAD_STATE_ADDING);
+			MARS_BITS_SET(&bits, WORKLOAD_KERNEL_ID,
+				      MARS_KERNEL_ID_NONE);
 			mars_ea_put_uint64(get_block_bits_ea(block_ea, index),
 					   bits);
 			ret = index;

The 'WORKLOAD_KERNEL_ID' for a workload is actually reset when a new
workload is created in that workload slot. The reason for this is if a
workload runs and finishes, and the same workload is re-scheduled and
executed by the same kernel, the same workload is still cached in MPU
storage.

It is guaranteed that the workload ELF has not changed for that workload
until it is destroyed or a new workload has been created in that slot
(workload_id). Since a destroyed workload cannot be scheduled for
execution, I think it is sufficient to reset the 'WORKLOAD_KERNEL_ID'
at the time of workload creation into that workload_id slot.

Currently the task module does not make use of this feature because it
does not differentiate the text section and data sections when loading
the workload. In the future we may plan to. So the above feature might
allow for avoiding unnecessary dma of text section + read-only sections
when the same workload is scheduled repeatedly.

Regards,
Yuji