Pondering machvec ... was: [Patch] Remove sn2_defconfig.

Pondering machvec ... was: [Patch] Remove sn2_defconfig.

[Luck, Tony]

>    Not really a patch as much as a remove this file request.  Now that
>    generic_defconfig supports all the configurations SGI currently supports
>    and has NR_CPUS and NR_NODES at our largest configurations, we have no
>    reason to maintain the extra defconfig file.

I'm wondering whether we really want to do this ... and in turn wondering
about the value of the "generic" vs. system specific config files and the
whole machvec mechanism.

If the config files is removed, then the occasional breakage that it
finds will go unseen.  How much does this matter?  Not having it would
speed by regression build sequence (sn2 takes the longest of all the
builds I do).

I primarily test tiger_defconfig kernels on Intel systems and zx1_defconfig
kernels on HP systems ... with just the occasional boot test of a
generic_defconfig kernel to make sure it hasn't been severely broken.

Most end users are using distribution kernels ... which are based on
generic kernels because distributors don't want to maintain a slew of
separate binaries.

Now there are possibly some performance benefits from using a platform
specific kernel (reduced cpu usage because the indirection through
machvec is eliminated, plus reduced memory footprint for the kernel).
Has anyone ever tried to measure these?  Are they worth the extra
maintenance and testing needed to keep machvec alive?

-Tony

Re: Pondering machvec ... was: [Patch] Remove sn2_defconfig.

[Robin Holt]

I am not addressing anything other than the sn2_defconfig, but it
has gotten so stale that nobody I know inside SGI uses it any longer.
We either maintain our own config file or start with the generic_defconfig
and adjust the things we need.

If any of our engineers wanted to eliminate the mach_vec stuff, we would
likely start from the generic_defconfig and change _GENERIC to _SN2.

On Fri, Aug 15, 2008 at 10:20:03AM -0700, Luck, Tony wrote:
> >    Not really a patch as much as a remove this file request.  Now that
> >    generic_defconfig supports all the configurations SGI currently supports
> >    and has NR_CPUS and NR_NODES at our largest configurations, we have no
> >    reason to maintain the extra defconfig file.
> 
> I'm wondering whether we really want to do this ... and in turn wondering
> about the value of the "generic" vs. system specific config files and the
> whole machvec mechanism.

I don't think I understand your argument.  Are you essentially saying we
should consider eliminating the mach_vec stuff entirely?  If so, will
we essentially be saying that the distros need to build a seperate kernel
for each of tiger, zx1, sn2, and uv?

Thanks,
Robin

RE: Pondering machvec ... was: [Patch] Remove sn2_defconfig.

[Luck, Tony]

> I don't think I understand your argument.  Are you essentially saying we
> should consider eliminating the mach_vec stuff entirely?  If so, will
> we essentially be saying that the distros need to build a seperate kernel
> for each of tiger, zx1, sn2, and uv?

No ... exactly the opposite ... I'm wondering whether we should give
up maintaining/building all the tiger_, zx1_ configs and only have the
generic one ... since it appears that the number of end users of non-generic
kernels can be counted on the toes of one foot.

-Tony

Re: Pondering machvec ... was: [Patch] Remove sn2_defconfig.

[Robin Holt]

On Fri, Aug 15, 2008 at 11:56:07AM -0700, Luck, Tony wrote:
> > I don't think I understand your argument.  Are you essentially saying we
> > should consider eliminating the mach_vec stuff entirely?  If so, will
> > we essentially be saying that the distros need to build a seperate kernel
> > for each of tiger, zx1, sn2, and uv?
> 
> No ... exactly the opposite ... I'm wondering whether we should give
> up maintaining/building all the tiger_, zx1_ configs and only have the
> generic one ... since it appears that the number of end users of non-generic
> kernels can be counted on the toes of one foot.

I won't speak to the others, but as for sn2_defconfig SGI appears to
still be a go.  I did get feedback from a couple engineers that had been
using the sn2_defconfig, but both seem to accept the generic_defconfig
as an adequate substitue now that it has our needed disk drivers.


Thanks,
Robin

Re: Pondering machvec ... was: [Patch] Remove sn2_defconfig.

[Jes Sorensen]

Luck, Tony wrote:
>> I don't think I understand your argument.  Are you essentially saying we
>> should consider eliminating the mach_vec stuff entirely?  If so, will
>> we essentially be saying that the distros need to build a seperate kernel
>> for each of tiger, zx1, sn2, and uv?
> 
> No ... exactly the opposite ... I'm wondering whether we should give
> up maintaining/building all the tiger_, zx1_ configs and only have the
> generic one ... since it appears that the number of end users of non-generic
> kernels can be counted on the toes of one foot.

Hi Tony,

IMHO it would be fine to just run the generic builds and forget about
the specialized ones. We can probably simplify the machvec
infrastructure a bit by doing so, but I don't see how we're going to get
rid of the bulk of it..... says the guy who is in the process of adding
more entries :-)

Cheers,
Jes