You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a Cloudlet is submitted to a VM and may wait in a queue until the VM has enough PEs to execute the Cloudlet (according to the CloudletScheduler policy).
After a Cloudlet is scheduled using a CloudletSchedulerTimeShared, it will share the CPU with other concurrent Cloudlets. This way, multiple Cloudlets are executed preemptively (i.e., interchangeably).
However, the time a preempted Cloudlet is supposed to wait until be scheduled again is not computed.
The oversimplified CloudletSchedulerTimeShared doesn't actually perform preemption, but just reduces the amount of MIPS a Cloudlet can use when there are more Cloudlets than CPU cores.
This way, it enables all Cloudlets to run at the same time (which is not possible with current processor technologies). Check issues #27, #33 and #58 for more details.
When a CloudletSchedulerSpaceShared is used, when there are fewer CPU cores than Cloudlets, the next Cloudlet just starts executing when a previous one completely finishes its execution. This wait time is not computed either.
The Cloudlet.getWaitingTime() method returns the time the Cloudlet waited before starting executing, not the intermediate wait time after the Cloudlet started executing but was descheduled (preempted) for some reason. Before the implementation of Google Cluster Data readers (#149), a Cloudlet was never descheduled, but now this is a reality (as it is in real CPU scheduling).
It has to be assessed if the Cloudlet.getWaitingTime() will be used just to return the time the Cloudlet waited to be scheduled for the first time (as it is now) and a new method such as getTotalWaitingTime() will be introduced that adds up the intermediate waiting times. Possibly the first method should be renamed to getStartWaitingTime().
The text was updated successfully, but these errors were encountered:
manoelcampos
changed the title
The time a Cloudlet waits after be preempted is not computed
The time a Cloudlet waits after being preempted is not computed
Aug 16, 2018
Hey @krupaJari
Sorry for the late reply. I've been very busy these days.
That is great. If you want to start working on this, just let me know and send a PR.
You don't need to wait for it to be done to send the PR. This way, I can provide some guidance.
Do you have anything in mind already on how to design a solution? It would be great if you provide your thoughts abouth the discussion on the issue above.
The regular Cloudlet workflow is as follow:
CloudletSchedulerTimeShared
, it will share the CPU with other concurrent Cloudlets. This way, multiple Cloudlets are executed preemptively (i.e., interchangeably).However, the time a preempted Cloudlet is supposed to wait until be scheduled again is not computed.
The oversimplified
CloudletSchedulerTimeShared
doesn't actually perform preemption, but just reduces the amount of MIPS a Cloudlet can use when there are more Cloudlets than CPU cores.This way, it enables all Cloudlets to run at the same time (which is not possible with current processor technologies). Check issues #27, #33 and #58 for more details.
When a CloudletSchedulerSpaceShared is used, when there are fewer CPU cores than Cloudlets, the next Cloudlet just starts executing when a previous one completely finishes its execution. This wait time is not computed either.
The
Cloudlet.getWaitingTime()
method returns the time the Cloudlet waited before starting executing, not the intermediate wait time after the Cloudlet started executing but was descheduled (preempted) for some reason. Before the implementation of Google Cluster Data readers (#149), a Cloudlet was never descheduled, but now this is a reality (as it is in real CPU scheduling).It has to be assessed if the
Cloudlet.getWaitingTime()
will be used just to return the time the Cloudlet waited to be scheduled for the first time (as it is now) and a new method such asgetTotalWaitingTime()
will be introduced that adds up the intermediate waiting times. Possibly the first method should be renamed togetStartWaitingTime()
.The text was updated successfully, but these errors were encountered: