<div dir="ltr">Hi Björn <div><br></div><div>I am a student from the University of York working with Alan and Andy to study MrsP nested behaviours now.</div><div><br></div><div>We now have a full implementation of nested MrsP under Litmus P-FP scheduler and we are now trying to do some evaluations of the implementation overheads.</div><div><br></div><div>We use the feather-trace tool to trace the overheads of the scheduler (which includes the P-FP schedule function), context switch (includes finish_switch function), mrsp_lock and mrsp_unlock function. </div><div><br></div><div>During evaluation, we fixed the CPU clock speed, bounds interrupts to cpu 0 and isolate other cpus for testing to minimise the interference from the system.</div><div><br></div><div><br></div><div>However, the result seems werid. Use mrsp_lock as an example: we evaluated the overhead of the following code using the timestamps "TS_LOCK_START" and "TS_LOCK_END".</div><div><br></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre">      </span>TS_LOCK_START;</div><div><br></div><div><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>if (t->rt_param.task_params.helper == NULL) {</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">               </span>t->rt_param.task_params.priority = sem->prio_per_cpu[get_partition(t)] < get_priority(t) ? sem->prio_per_cpu[get_partition(t)] : get_priority(t);</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">          </span>t->rt_param.task_params.migrated_time = -1;</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>}</div><div><br></div><div><span class="gmail-Apple-tab-span" style="white-space:pre">     </span>ticket = atomic_read(&sem->next_ticket);</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>t->rt_param.task_params.ticket = ticket;</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">    </span>atomic_inc(&sem->next_ticket);</div><div><br></div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>add_task(t, &(sem->tasks_queue->next));</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">      </span>t->rt_param.task_params.requesting_lock = sem;</div><div><br></div><div><span class="gmail-Apple-tab-span" style="white-space:pre">     </span>TS_LOCK_END;</div></div><div><br></div><div>Where function add_task() is as follows:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>void add_task(struct task_struct* task, struct list_head *head) {</div></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>struct task_list *taskPtr = (struct task_list *) kmalloc(sizeof(struct task_list), GFP_KERNEL);</div></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>BUG_ON(taskPtr == NULL);</div></div><div><div><br></div></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>taskPtr->task = task;</div></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>INIT_LIST_HEAD(&taskPtr->next);</div></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre">  </span>list_add_tail(&taskPtr->next, head);</div></div><div><div>}</div></div><div><br></div></blockquote>We expect the overheads of the code above to be stable as the time complexity is order 1. However, the testing result gives us a different story, as shown below:<div><br></div><div>Overhead        Overhead        Unit        Samples        MAX        99.9th perc.        99perc.        95th perc.        avg        med        min        std        var</div><div>MRSP             LOCK             cycles    149985          20089       2220.016            1584            1287            853.9508    939        319     367.314  134918.7<br><div><br></div><div><div>As we can see, the max overheads we have is 20089 cycles, which is far bigger than the med/avg value and even the 99.9the perc value.</div></div></div><div><br></div><div>I am confused about this result. I wonder have you meet this situation before? Is there any explanation for the result like this? or is there any way to avoid this?</div><div><br></div><div>Thank you in advance.</div><div><br></div><div>Best wishes</div><div>Shuai</div></div>