Re: lack of boot-time entropy on arm64 ec2 instances
On Tue, Jan 14, 2020 at 03:01:23PM +0000, Luca Filipozzi wrote:
> > If we want to extend the cloud kernel to support other services, we need
> > to do more than just enable virtio-rng. Somebody need to come up with a
> > complete list of devices that are needed for the service in question,
> > and work with the kernel team ensure that support for all of them is
> > enabled in the cloud kernel.
>
> Folks working on the CCP, etc.: is it of interest to you to use the same
> cloud kernel? Does this improve our users' experience to have the same
> kernel across the different providers?
At present the cloud kernel's only optimizations consiѕt of disabling
device drivers that are highly unlikely to be seen in a cloud
environment. So the user experience is the same, except for the larger
/lib/modules/$(uname -r) directory and the larger initramfs image. The
size of the initramfs does, of course, contribute to boot latency by
taking longer to uncompress, but I haven't quantified the difference
yet. So for now, the cloud flavour is the conservative choice, in that
we know it will work and the drawbacks of using it are fairly minor.
There is talk of making some additional changes. Bug #947759 contains a
decent summary of things that are being considered. There is also
#941284, but my inclination is to not implement that suggestion. In any
case, we'll need to consider the impact of any proposed changes on the
user experience in the supported clouds on an ongoing basis.
In an ideal world, we might be able to provide distinct flavours for
each cloud, since e.g. it makes no sense to enable the Amazon ENA
ethernet driver on kernels targeting environmnents other than AWS, but
that would require more resources for diminishing returns.
noah
Reply to: