pod: Improve pod create performances#484
Conversation
sboeuf
force-pushed
the
sboeuf/improve_start_vm
branch
2 times, most recently
from
71f8940 to
918b7b1
Compare
| vmStartedCh := make(chan error) | ||
| const timeout = time.Duration(10) * time.Second | ||
|
|
||
| go p.hypervisor.waitPod(vmStartedCh) |
There was a problem hiding this comment.
Can we simply make waitPod blocking and pass it a timeout instead?
There was a problem hiding this comment.
Sure I can do that. The reason I have chosen such an implementation is to avoid the duplication of timeout handling for every hypervisor implementation.
|
|
||
| q.Logger().WithError(err).Warn("Failed to connect to QEMU instance, retrying...") | ||
| time.Sleep(time.Duration(50) * time.Millisecond) | ||
| } |
There was a problem hiding this comment.
This potentially is an infinite loop. By giving waitPod a timeout, you could implement a non infinte loop here based on the timeout argument.
There was a problem hiding this comment.
Yes I agree, but I thought that every hypervisor implementation will have to implement the same mechanism which is duplication. I know this could be an infinite loop but when the main process returns, this go routine is gonna be terminated.
| break | ||
| } | ||
|
|
||
| q.Logger().WithError(err).Warn("Failed to connect to QEMU instance, retrying...") |
There was a problem hiding this comment.
I would not print a new log entry every 50ms, but print one if we timeout instead.
|
@sameo I am gonna make the changes ;) |
sboeuf
force-pushed
the
sboeuf/improve_start_vm
branch
from
918b7b1 to
2f3541c
Compare
|
LGTM
|
|
@sameo comments addressed ! |
In order to optimize pod creation, this patch does not wait for the VM after it has been started. Instead, it will wait for it during the "start" stage. This will allow our VM to be started while the caller could potentially do other things between create and start. Globally, this improves the boot time of our containers. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
sboeuf
force-pushed
the
sboeuf/improve_start_vm
branch
from
2f3541c to
b20ba87
Compare
2 participants
pod: Improve pod create performances
In order to optimize pod creation, this patch does not wait for the
VM after it has been started. Instead, it will wait for it during the
"start" stage. This will allow our VM to be started while the caller
could potentially do other things between create and start. Globally,
this improves the boot time of our containers.