Proposal: the 'faster' branch.

C. Scott Ananian cscott at laptop.org
Fri Feb 8 15:22:44 EST 2008


There are a number of high risk changes which seem necessary to get
the performance we would like from our builds.   In addition to
tomeu's recent rainbow patches, I could list: partitioning the root
filesystem, using logfs/jffs3/ufs instead of jffs2 for our
filesystems, starting X as early as possible in the boot process,
radically trimming the udev rule list, radically trimming the
initscript and rc.sysinit, rewriting portions of sugar in C, and
others.

There are all "bad ideas" in various ways: they may introduce
divergences from upstream, their savings are unproven, they may add to
our support problems in the field, they may involve immature
technologies.  But (IMO) it's time to stop being scared and see what
we could do if all the fetters were off.

So: welcome the 'faster' branch, a repository for all these unsafe
ideas.  It will be completely untested and may eat your machine.  But
let's see how fast we could make things if we allowed all our evil
hacks, and *then* step back and evaluate which of these turned out to
be useful and which of these are (still) too expensive or ugly to try.
 Nothing in 'faster' in guaranteed to make it into our stable branch,
ever.  But perhaps it will help show us the way forward.

Faster is set up like joyride.  Put rpms in dev:~/public_rpms/faster.
Please keep your ugly hacks safely separate from code you intend real
people to use.  Discuss.  Enjoy.
 --scott

p.s. Michael Stone asked me a question before I'd managed to send this
out, so I'll answer him here for all of you: 'Faster' code is not
intended to be put into joyride or stable ever.  The idea is, don't
waste (too much) time (yet) doing things the "right" way.  Just hack
up the code and show us what's possible.  Once we're convinced that we
can get (say) boot time down to less than a second, we can figure out
how to clean up the hacks and make things work for real/in a
maintainable fashion.  But 'faster' is specifically for dirty hacks
and proofs-of-concept.

-- 
                         ( http://cscott.net/ )



More information about the Devel mailing list