Carrier Grade Linux/Gaps Alpha1

[tytso@xxxxxxx (Theodore Tso)]

On Tue, May 27, 2008 at 10:23:56AM -0700, Greg KH wrote:
> See previous message (1% speed increase was the best possible
> measurement that I got, but the variance in booting was about 5%
> overall, so it was lost in the noise pretty much all the time.)

It should be noted that on a typical system there's typically only one
probe which takes a loooooong time and that's the SCSI/FC bus
enumeration.  So even if you parallelize everything else, it's not at
all surprising that the reduction would only be 2 seconds.  I suppose
it would be possible to construct some use case with specialized
device drivers which take long time to probe, running in parallel with
the hard drives --- but it might be that there are other ways of
solving that problem, such building the specialized telecom driver as
a module and modprobing during the rc.scripts, so it could run in
parallel with the boot sequence.  That might be a **much** cheaper way
of solving the problem, for a very specialized case, instead of trying
to solve the general problem which doesn't even help for 99.93% of
Linux users which typically only have one device driver which takes a
long time to probe (and which still isn't the major slow step in a
typical Enterprise Linux distribution boot timeline).

I would advocate just throwing out this requirement, because the high
level requirement, "decrease boot time", is so application and
hardware configuration specific that it really must be handled on a
case-by-case basis.

And perhaps that's the main problem with these low-level requirements.
They basically seem to assume that the only way of solving it is the
way the NEP's have specified, and that they aren't willing to make any
changes to their application code, or boot scripts, or anything else
in order to solve their high level problem.  Worse yet, there doesn't
seem to be way to represent how much they are willing to pay to have
some feature --- so they are basically saying, "I want a pony --- and
it must be British Spotted Pony --- and *you* get to pay for it".

If instead the NEP's are willing to say, this feature is worth $X
hundred thousand dollars to me, and I am willing to pay that amount,
it helps weed out the junk requirements, and implicitly shows that
explored alternatives that might have been cheaper/easier to
implement, and which haven't worked out for them.  So perhaps part of
the problem with CGL is the economic model hasn't really been thought
three --- perhaps having a stronger connection between the cost to
implement a feature, and what various NEP's are willing to pay to make
sure such a feature exists would make life a little easier.

Regards,

						- Ted