Optimizing RCng execution speed ?

Peter Jeremy peterjeremy at optushome.com.au
Wed Apr 14 03:28:16 PDT 2004

On Wed, Apr 14, 2004 at 07:54:11AM +0100, Colin Percival wrote:
>At 21:00 13/04/2004, Peter Jeremy wrote:
>>If someone wants to have a look at this,
>>the place to start is to profile the complete system during startup
>>and see where the time is going.
>  On my 5.2.1 system (with the mentioned don't-reload-rc.subr patch):
>Starting RC scripts:                    kern.cp_time: 1 0 44 2 53
>RC scripts done:                        kern.cp_time: 71 0 455 5 819

Overall, that's 61% idle, 33% sys and 6% user.  I suspect the 'idle'
time is virtually all waiting for disk I/O.  Someone else (green@ ?)
has commented that increasing parallelism slowed things down - which
is consistent with system startup being I/O bound.

This doesn't seem too unlikely:
- The system is starting from cold so the filesystem cache is empty.
  Most read(2) calls and page-faults will require physical I/O.
- Many of the scripts just spawn a daemon process.  These generally
  daemonise fairly early and do most of their startup in the background -
  colliding with all the other daemons doing the same thing.

It may sound counter-intuitive but adding some judicious short sleeps
(a few ticks each) during startup could speed things up by reducing the
disk contention.

The other option is to add a kernel hook(s) that records physical disk
reads into a file and then uses that file to pre-load the filesystem
and VM cache (in sequential order rather than randomly).  This assumes
enough RAM to be able to load all the necessary disk blocks - but that
is probably the norm nowadays.

Next step is where all the kernel time is going.  This probably means
running a profiled kernel or ktrace()ing into a ramdisk.


More information about the freebsd-current mailing list