Skip to content

Migrate Metrics and the Serial device to EventManager (polly) #1494

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

acatangiu
Copy link
Contributor

@acatangiu acatangiu commented Jan 8, 2020

Reason for This PR

Another step in migrating Firecracker to the new polly event manager.

Fixes #1522
Fixes #1523

Description of Changes

Metrics

Both LOGGER and METRICS are Firecracker specific, not Vmm specific, and thus should not be tied to the Vmm.
Logger has already been taken out of Vmm, now take the metrics periodic logging logic out of the Vmm as well.

A PeriodicMetrics object is defined in the firecracker crate, which uses EventManager to drive periodic reporting of METRICS.

Serial

The serial device no longer has to be injected with input from some external component. It can now be created with any input object that is dyn std::io::Read + std::os::unix::io::AsRawFd.
Because the serial now implements the EventHandler trait, it can internally handle all input.

Removed the EpollDispatch::Stdin previously handled by the Vmm.

The builder can now build a Serial device with any input and/or output sources.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license.

@acatangiu acatangiu self-assigned this Jan 8, 2020
@acatangiu acatangiu added the Status: Awaiting review Indicates that a pull request is ready to be reviewed label Jan 8, 2020
@acatangiu acatangiu changed the title Metrics driven by polly outside of Vmm Migrate Metrics and the Serial device to EventManager (polly) Jan 17, 2020
@acatangiu
Copy link
Contributor Author

acatangiu commented Jan 17, 2020

@alexandruag @iulianbarbu @sandreim please review the integration of Metrics and Serial with the new event handling mechanism EventManager.

I still need to add tests before this PR is merge-able.

@acatangiu acatangiu force-pushed the metrics branch 3 times, most recently from 018d6d2 to e635475 Compare January 21, 2020 15:18
@acatangiu
Copy link
Contributor Author

@alexandruag @aghecenco @iulianbarbu I've also added tests, this PR is now complete. Please review.

sandreim
sandreim previously approved these changes Jan 23, 2020
Both LOGGER and METRICS are Firecracker specific, not Vmm specific,
and thus should not be tied to the Vmm.
Logger has already been taken out of Vmm, now take the metrics
periodic logging logic out of the Vmm as well.

A PeriodicMetrics object is defined in the firecracker crate, which
uses polly to drive periodic reporting of METRICS.

Signed-off-by: Adrian Catangiu <[email protected]>
sandreim
sandreim previously approved these changes Jan 27, 2020
// Start the metrics.
firecracker_metrics
.lock()
.expect("Unlock failed.")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: a more specific panic message would be nice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

}

// Only used in tests, but has virtually no cost in production.
self.flush_counter += 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: #[cfg(test)]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

error[E0658]: attributes on expressions are experimental

this is a simple counter with just increments on every flush (every 60s) so it's no runtimecost. Its purpose is to enable testing, without it we would have to drop the unittest..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can wrap it in a code block instead:

#[cfg(test)] {
            self.flush_counter += 1;
        }

let interrupt_evt = EventFd::new(libc::EFD_NONBLOCK)
.map_err(Error::EventFd)
.map_err(StartMicrovmError::Internal)?;
let protected_serial = EventManager::wrap_handler(devices::legacy::Serial::new_in_out(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Unnecessary overhead in naming the serial as protected_serial, serial would do just fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

let wrapped_handler = Arc::new(Mutex::new(handler));
self.register_protected(wrapped_handler.clone())?;
Ok(wrapped_handler)
pub fn wrap_handler<T: EventHandler + 'static>(handler: T) -> Arc<Mutex<T>> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this only appears to call Arc::new(Mutex::new(...)), is it really needed? It looks like invoking that sequence ourselves is also a bit shorter and clearer than writing EventManager::wrap_handler(...).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Signed-off-by: Adrian Catangiu <[email protected]>
The serial device no longer has to be injected with input from
some external component. It can now be created with any input
object that is 'dyn std::io::Read + std::os::unix::io::AsRawFd'
and because the serial implements the EventHandler trait, it can
internally handle all input.

Removed the EpollDispatch::Stdin previously handled by the Vmm.

The builder can build a Serial device with any input and/or output
sources.

Signed-off-by: Adrian Catangiu <[email protected]>
'register()' shouldn't take ownership of the handler because it could
fail and on the Err path it would drop the handler.
Instead of taking ownership and wrapping it then returning it in an
Arc<Mutex>, just take an Arc<Mutex>. This way, the caller has maximum
flexibility and can choose to provide a simple clone and doesn't
lose the handler in an error case.

Signed-off-by: Adrian Catangiu <[email protected]>
Remove the `RawIOHandler` trait exposed by `bus.rs`. This was
previously used to get a handle on the Serial device to be able
to externally inject raw input in it.

With the new Serial design, that is no longer necessary, the Serial
device itself can be built with any input/output sources and it will
handle input and output on them internally.

Signed-off-by: Adrian Catangiu <[email protected]>
@acatangiu acatangiu merged commit eaac3ce into firecracker-microvm:refactoring/epoll_handler Jan 27, 2020
@acatangiu acatangiu deleted the metrics branch February 17, 2020 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting review Indicates that a pull request is ready to be reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants