[SGVLUG] Time to boot getting longer with Debian

[Emerson, Tom]

> -----Original Message----- Of David Lawyer
> On Sat, Apr 22, 2006 at 12:58:58PM -0700, John E. Kreznar wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > David Lawyer <dave at lafn.org> writes:
> > 
> > > I just installed kernel 2.6.15 on my 11-year-old PC and it takes 
> > > over 3 min. to boot. ... I could track down the delays ....
> > 
> > 2.6.16 (and maybe 2.6.15 as well?) has a new configuration parm
> > PRINTK_TIME described as follows.
> [snip]
> Thanks for the info but if I watch the boot-time messages I 
> can see a few places where it pauses far too long (I think) 
> so I'll work on these first without using any timing tools.  
> I've sent in the first bug report on this [...]

Speaking as someone who has manned the other end of the phone on calls
like that, saying "I think it's taking too long" when your only proof is
subjective will be resolved in the bit bucket.  OTOH, providing proof
that some (presumably) unchanged process now takes anywhere from 5 to 50
times longer than before will get some attention.

> [...] and hope the reply 
> isn't to get a faster PC to work around inefficiencies and bloat.

What reply would you be satisfied with?  Perhaps the process you are
watching is now running in parallell with some other process, so the
elapsed or wall time is indeed longer, but the actual processing time
/devoted to this item/ is unchanged or even (heaven forbid!) /faster/.
Unfortunately, researching a timing issue like this to find out that the
order of operations has changed between console messages is way down on
the food chain, so it is easier to say "get a faster machine" and not
worry about it.

> I've gotten such responses from Debian maintainers in the 
> past. A bug was introduced in the latest revision of module 
> load tools so that the ppp module of kernel 2.2.20 doesn't 
> load (but other modules for 2.2.20 do load).

If an older module was written in a way that was marginally acceptable
in the past but is now incompatable, then I'd support the "upgrade or
die" philosophy [of course, I don't know offhand the quality of the
module in question nor what actually "broke" between 2.2.20 and now, but
I suspect that any fix to the 2.2.20 version would be significant.
Also, I just realized what you're saying (or implying?) is that you're
trying to load a 2.2 version of a module in a 2.6 kernel -- that sounds
extremely suspect to me.  Is there no "version 2.6" of this module?]

> Without the ppp module I can't connect to the Internet 

Hmmm... Given how critical this module would be to "everyone", I'd
imagine there is a proper 2.6 version of the module -- is there a
particular reason you are avoiding it's use?

> ...  The response was 
> that 2.2.20 is no longer supported.  But I'm appealing this 
> and will let this list know if I succeed in getting this bug fixed.

If I understand this, you're asking that the 2.6 kernel fully support an
older version of a module when there may be a perfectly good "current"
version of that same module, correct?

> And when Tom E. wrote that the longer boot times might be a 
> price we pay for progress, I think it's a price we pay for 
> not having people like me that complain about it, try to find 
> the causes for it, and get them fixed.

My previous comment about the "price of progress" is the fact that the
kernel [should be] doing /significantly/ more now than in the past.
Overall strategies and methods may have changed, so it's not surprising
to see different (and generally longer) times to accomplish the same
thing as in the past.  The article I referrenced did point out, however,
that something as simple as an "fopen" was being performed some 80,000+
times!  Each fopen, in turn, would end up calling a "walk the directory
tree" routine, which then gets down to (possibly un-cached) disk reads
and associated I/O.  Some investigation into this revealed that things
like .conf files were being repeatedly opened, parsed, and closed by the
same process (as opposed to perhaps caching the information retrieved to
avoid further fopens), so there was an underlying philosophy problem [of
referrencing a file on disk /every time/ to evaluate a configuration
parameter instead of storing the result locally] that is now bordering
on the "extreme" when spread across /every/ kernel initialization
process.

But, as pointed out elsewhere on this thread, there is a trade off being
taken into consideration: if the /only/ time a procedure ends up being
"wasteful" is during startup, then it is unlikely to be optimized or
"repaired" because the net effect of fixing that process is negligable
over the "uptime" of a given system.  OTOH, if improving some kernel
startup process /also/ improves day-to-day operation of that process,
then by all means optimizing or "fixing" that process should become a
priority.