Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #94654 > unrolled thread

Re-designating cloud kernel

Back to article view | Back to linux.debian.kernel

Contents

  Re-designating cloud kernel Bastian Blank <waldi@debian.org> - 2026-10-28 15:10 +0100
    Re: Re-designating cloud kernel Noah Meyerhans <noahm@debian.org> - 2026-10-28 15:50 +0100
      Re: Re-designating cloud kernel Noah Meyerhans <noahm@debian.org> - 2026-10-28 20:30 +0100
      Re: Re-designating cloud kernel Ross Vandegrift <rvandegrift@debian.org> - 2026-10-28 21:00 +0100
      Re: Re-designating cloud kernel Bastian Blank <waldi@debian.org> - 2026-10-30 13:10 +0100
        Re: Re-designating cloud kernel Noah Meyerhans <noahm@debian.org> - 2026-10-30 16:20 +0100

#94654 — Re-designating cloud kernel

Hi folks

We currently build a separate cloud kernel for amd64 and arm64.  It is
meant for usage on specific cloud platforms, AWS, Azure and GCP.  This
however does not mean users will not assume it to be usable on all
virtualized platforms.

Since some time I wonder if it would be useful and possible to
re-designate (and later rename) this kernel for "all" virtualized
platforms.  Most of them already work anyway, as they all expose similar
hardware, not the same but similar.

We currently already include:
- Complete non-root support for HyperV.
- Complete non-root support for XEN.
- Support for many of the devices exposed by qemu in both pc and q35 mode.

What is known to be missing:
- Support for VirtualBox.

What else?  The question is then also: should we then re-add support for
stuff like GFS or so?

Also in the near future, the second build will go away and we will only
have a stripped down modules package left.  So in the future we'll
select by module, not longer by config.

Bastian

-- 
No one wants war.
		-- Kirk, "Errand of Mercy", stardate 3201.7

[toc] | [next] | [standalone]

#94655

On Wed, Oct 28, 2026 at 02:42:47PM +0100, Bastian Blank wrote:
j We currently build a separate cloud kernel for amd64 and arm64.  It is
> meant for usage on specific cloud platforms, AWS, Azure and GCP.  This
> however does not mean users will not assume it to be usable on all
> virtualized platforms.
> 
> Since some time I wonder if it would be useful and possible to
> re-designate (and later rename) this kernel for "all" virtualized
> platforms.  Most of them already work anyway, as they all expose similar
> hardware, not the same but similar.

I agree with all of this.

> We currently already include:
> - Complete non-root support for HyperV.
> - Complete non-root support for XEN.
> - Support for many of the devices exposed by qemu in both pc and q35 mode.
> 
> What is known to be missing:
> - Support for VirtualBox.
> 
> What else?  The question is then also: should we then re-add support for
> stuff like GFS or so?
> 
> Also in the near future, the second build will go away and we will only
> have a stripped down modules package left.  So in the future we'll
> select by module, not longer by config.

How granular do you plan on making the modules packages?  Use cases for
things like filesystems and network protocols are likely going to be the
same across cloud and non-cloud deployments, so it might make sense to
have a "common" modules package that's installed by default in just
about all cases.  The major differences between virtualization platforms
is in the device models they expose to guests.  Would it be feasible to
offer dedicated "aws", "hyperv/azure", "gcp", etc driver packages that
provide hardware support for those specific environments?  Or is that
too much work/overhead?  The benefit of such disk space optimizations
can be significant when scaled across hundreds or thousands of systems.

For the record, I don't love the idea of eliminating the second kernel
build.  While we haven't taken advantage of this opportunity to this
point, it allows us to provide build-time optimizations to best tune
performance for specific deployment scenarios.  But I suppose runtime
tuning is sufficient for most people, as we haven't received any
requests for different build-time optimizations afaik.  So I don't
object too strongly to the plan, and I understand that it offers some
advantages.

noah

[toc] | [prev] | [next] | [standalone]

#94661

On Wed, Oct 28, 2026 at 11:53:46AM -0700, Ross Vandegrift wrote:
> > For the record, I don't love the idea of eliminating the second kernel
> > build.  While we haven't taken advantage of this opportunity to this
> > point, it allows us to provide build-time optimizations to best tune
> > performance for specific deployment scenarios.  But I suppose runtime
> > tuning is sufficient for most people, as we haven't received any
> > requests for different build-time optimizations afaik.  So I don't
> > object too strongly to the plan, and I understand that it offers some
> > advantages.
> 
> Are there specific optimizations you have in mind that would become
> impossible?

CONFIG_HZ_* is an example that comes to mind.  Changing that for the
cloud kernels was requested several years ago (see #941284) and we
decіded not to do it, so I'm just mentioning that as a specific example,
not a proposal.  There are likely other such compile-time tunables that
might be worth considering.

noah

[toc] | [prev] | [next] | [standalone]

#94663

On Wed, Oct 28, 2026 at 10:41:15AM -0400, Noah Meyerhans wrote:
> On Wed, Oct 28, 2026 at 02:42:47PM +0100, Bastian Blank wrote:
> > Since some time I wonder if it would be useful and possible to
> > re-designate (and later rename) this kernel for "all" virtualized
> > platforms.  Most of them already work anyway, as they all expose similar
> > hardware, not the same but similar.
> 
> I agree with all of this.

Yep - we did this at $dayjob to avoid vendor-specific kernels and it's
been good.

> > We currently already include:
> > - Complete non-root support for HyperV.
> > - Complete non-root support for XEN.
> > - Support for many of the devices exposed by qemu in both pc and q35 mode.
> > 
> > What is known to be missing:
> > - Support for VirtualBox.
> > 
> > What else?  The question is then also: should we then re-add support for
> > stuff like GFS or so?

Should we care about VMware's emulated physical fallbacks?  IIRC their
block layer emulates lsi logic, I think it uses mpt2.

Should we care about more networking virtual function drivers?  I know
igbvf, iavf, idpf aren't currently included.

I don't feel strongly - these are probably pretty specialized.

> > Also in the near future, the second build will go away and we will only
> > have a stripped down modules package left.  So in the future we'll
> > select by module, not longer by config.
> 
> How granular do you plan on making the modules packages?  Use cases for
> things like filesystems and network protocols are likely going to be the
> same across cloud and non-cloud deployments, so it might make sense to
> have a "common" modules package that's installed by default in just
> about all cases.

I think a lot turns on whether there's a useful division of the modules
into binary packages that *doesn't* create hundreds of them to juggle.

> The major differences between virtualization platforms
> is in the device models they expose to guests.  Would it be feasible to
> offer dedicated "aws", "hyperv/azure", "gcp", etc driver packages that
> provide hardware support for those specific environments?  Or is that
> too much work/overhead?  The benefit of such disk space optimizations
> can be significant when scaled across hundreds or thousands of systems.

There's also disagreement between the cloud vendors is when a driver
should be =m vs =y.  At work, I took the max of (n < m < y) since it's
safer from breakage.  But it might be nice to make more subtle
decisions, to implement the platform-specific packages?

> For the record, I don't love the idea of eliminating the second kernel
> build.  While we haven't taken advantage of this opportunity to this
> point, it allows us to provide build-time optimizations to best tune
> performance for specific deployment scenarios.  But I suppose runtime
> tuning is sufficient for most people, as we haven't received any
> requests for different build-time optimizations afaik.  So I don't
> object too strongly to the plan, and I understand that it offers some
> advantages.

Are there specific optimizations you have in mind that would become
impossible?

Ross

[toc] | [prev] | [next] | [standalone]

#94682

Hi

On Wed, Oct 28, 2026 at 10:41:15AM -0400, Noah Meyerhans wrote:
> How granular do you plan on making the modules packages?

In the first step it'll just be two conflicting packages, one with all,
one with just the virtualized stuff.

>                                                           Use cases for
> things like filesystems and network protocols are likely going to be the
> same across cloud and non-cloud deployments, so it might make sense to
> have a "common" modules package that's installed by default in just
> about all cases.

Maybe.  But for now I don't see a usecase for that.  It just saves a bit
of space on our mirrors, but instead of bloats the Packages files and
the dependency tree.

Fedora creates a -core package, but this is meant as standalone
installable and contains everything for a normal current system to work.

>                   The major differences between virtualization platforms
> is in the device models they expose to guests.  Would it be feasible to
> offer dedicated "aws", "hyperv/azure", "gcp", etc driver packages that
> provide hardware support for those specific environments?  Or is that
> too much work/overhead?  The benefit of such disk space optimizations
> can be significant when scaled across hundreds or thousands of systems.

I don't think there would be a real benefit from splitting it this far.
We already shave 3/4 from the size of the kernel package, saving another
1% is IMHO not worth the hassle.

> For the record, I don't love the idea of eliminating the second kernel
> build.  While we haven't taken advantage of this opportunity to this
> point, it allows us to provide build-time optimizations to best tune
> performance for specific deployment scenarios.

Noted.  I currently consider this to not have a high enough value for
that.  The current cloud kernel config got some larger problems in how
it tries to subtract config entries, not only add.  This work done here
will also be folded back into what we do for the installer and reduce
the complexity also.

Bastian

-- 
I'm frequently appalled by the low regard you Earthmen have for life.
		-- Spock, "The Galileo Seven", stardate 2822.3

[toc] | [prev] | [next] | [standalone]

#94685

On Fri, Oct 30, 2026 at 12:44:52PM +0100, Bastian Blank wrote:
> > How granular do you plan on making the modules packages?
> 
> In the first step it'll just be two conflicting packages, one with all,
> one with just the virtualized stuff.
> 
> >                                                           Use cases for
> > things like filesystems and network protocols are likely going to be the
> > same across cloud and non-cloud deployments, so it might make sense to
> > have a "common" modules package that's installed by default in just
> > about all cases.
> 
> Maybe.  But for now I don't see a usecase for that.  It just saves a bit
> of space on our mirrors, but instead of bloats the Packages files and
> the dependency tree.
> 
> Fedora creates a -core package, but this is meant as standalone
> installable and contains everything for a normal current system to work.
> 
> >                   The major differences between virtualization platforms
> > is in the device models they expose to guests.  Would it be feasible to
> > offer dedicated "aws", "hyperv/azure", "gcp", etc driver packages that
> > provide hardware support for those specific environments?  Or is that
> > too much work/overhead?  The benefit of such disk space optimizations
> > can be significant when scaled across hundreds or thousands of systems.
> 
> I don't think there would be a real benefit from splitting it this far.
> We already shave 3/4 from the size of the kernel package, saving another
> 1% is IMHO not worth the hassle.
> 
> > For the record, I don't love the idea of eliminating the second kernel
> > build.  While we haven't taken advantage of this opportunity to this
> > point, it allows us to provide build-time optimizations to best tune
> > performance for specific deployment scenarios.
> 
> Noted.  I currently consider this to not have a high enough value for
> that.  The current cloud kernel config got some larger problems in how
> it tries to subtract config entries, not only add.  This work done here
> will also be folded back into what we do for the installer and reduce
> the complexity also.

Ack. This all sounds good to me.  Thanks.

noah

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web