Carrier Grade Linux/Gaps Alpha1

[greg@xxxxxxxxx (Greg KH)]

On Tue, May 27, 2008 at 08:19:05AM -0600, Troy Heber wrote:
> On 05/26/08 21:01, Greg KH wrote:
> 
> > 	Priority: P3
> 
> The first thing you should take into account when looking at
> requirements is the priority which ranges from P1 to P3 with P1 being
> mandatory, P2 optional, and P3 "roadmap".
> 
> In this case the requirement is P3, thus it is a wishlist item.
> 
> > What is supposed to be achieved by this?
> 
> Obviously, faster boot times on multiprocessor machines. Just like the
> broken PCI_MULTITHREAD_PROBE attempted to achieve.

Did anyone ever prove that if you implemented this, you would get faster
boot times?  Or was it just a wild idea?

> > Why is it a requirement?
> 
> Because it was submitted to the CGL working group as requirement by a
> contributor who would like to see the feature implemented in the Linux
> kernel. It was evaluated by the working group, accepted, given an
> appropriate priority, and finally placed in the gaps documented.

{sigh}

I thought you all were moving away from the "accept a random feature
requriement" to the more useful "accept a problem that needs to be
solved" type model.

This specific example shows that an idea that might seem to be nice to
have, with no data to back it up, is really not a valid thing to want.

> > What is supposed to happen if this is implemented?
> 
> In a perfect world the implementation would be flawless resulting in
> faster boot times.

Are you sure that this is an area in which the boot time of Linux is
slow?  By what ratio in comparison to other areas?

> > Hint, it was implemented, went into a kernel.org kernel, and then later
> > removed, does anyone want to tell me why you all want it back in?
> 
> Yes, there was an implementation, it was proven to be very buggy and
> it was removed. However, that does not invalidate the concept.

As the person who implemented it, tested it, benchmarked it, and then
later removed it, I would strongly disagree with that statement.

> The idea of loading drivers in parallel on a SMP machine to decrease
> bootime is still a reasonable idea. Thus there is no good reason for
> the CGL workgroup to remove it from being a wishlist gap.

Except the fact that:
	- The overall boot time of a system shows that any potential
	  savings found by such an implementation is lost in the noise
	  of the test? [1]
	- The needed changes to properly implement this in a manner that
	  would be acceptable to "enterprise" customers would require
	  such massive changes, that no one has ever proposed a manner
	  in which they could possibly be done?

> > I thought you all were moving away from this kind of nonsense...
> 
> Why is it nonsense to have wishlist items? OK, we may not be able
> achieve full parallel diver initialization. It still a reasonable goal
> and any stride towards achieving it is still progress.

It's "nonsense" to have random wishlist items that do not explain why
you feel you need this kind of thing, nor what it is really trying to
achieve.

Nor does it describe the work that had possibly been done in the past,
the expected results, or the needed work that might be required to
achieve such a thing (hint, one of the sentances in that requirement
would entail such a massive rework of the module loading system and
every single driver in the kernel that it's obvious no one realizes this
is an unatainable fantasy for no real gain in the end.)

thanks,

greg k-h

[1] I tested this option on a lot of different hardware, and the most I
ever saw boot time decrease by was 2 seconds.  Note, that the overall
boot time on such a machine was about 2 minutes, so you need to put that
kind of savings in light of that (1.66% increase).