[linux-elitists] Re: Watch Greg dance away from the question I posed.

Justin Keyes twitch@port0.net
Sat Nov 1 15:31:12 PST 2003


I forwarded your forwarded post to my lug and it ended up having
a forwarding orgy and I got much more good information that you may want
to note.  [Note especially the 2nd response, as it is from a Red Hat
insider.] Here are both responses...

> This is a very interesting post; thanks!
> 
> I've wondered about this weird slowdown for a while.  It seems to come
> and go (see #4, below).  If you wade through the chain of bugzilla
> reports, it looks like there are four issues discussed:
> 
> 1) the default bdflush settings
> 2) LANG=en_US.utf8
> 3) "service foo start" is different from "/etc/init.d/foo start" but
> should not be.
> 4) Something's wrong with the way the VM handles cache buffers
> 
> #1 is easy to fix.  "/sbin/sysctl -w vm.bdflush="30 500 0 0 2560 15360
> 60 20 0" does seem to smooth things out a bit (response times aren't so
> jerky).  To make this change permanent, put the part after the -w into
> /etc/sysctl.conf.
> 
> #2 is not fixed, but is easy to get around.  I ran "time grep '^'
> /var/log/messages > /dev/null' with various LANG settings.
> With LANG=en_US.UTF-8, average REAL time was 3.380 seconds.
> With LANG=en_US, average REAL time was 0.003 seconds (YES, THAT'S A
> THOUSAND TIMES SLOWER).
> 
> I've filed a report in Bugzilla; they seem to be working on it.  In the
> meantime, 
> 
> Edit /etc/sysconfig/i18n and change LANG="en_US.utf8" to LANG="en_US". 
> Also move the *.UTF-8* entries in SUPPORTED to the end of the list, like
> this:
> SUPPORTED="en_US:en:en_US.UTF-8"
> 
> 
> 
> #3 is a security problem.  A long, long time ago in a place not far from
> here, I was taught that daemons should always start with a clean
> environment.  "service foo start" does this, but "/etc/init.d/foo start"
> does not.  The bug is in /etc/init.d/functions, in the definition of
> daemon().  This function should call 'env -i' to clear the environment
> before starting a daemon but does not.  RedHat is reluctant to rush a
> fix through because several existing daemons apparently depend on having
> an environment.
> 
> 
> #4 is ugly, plain and simple.  The bdflush trick helps but doesn't solve
> this problem.  RedHat's kernel guys seem to be working with Linus & crew
> to figure out what's wrong; they aren't sure, yet, if it's one of Red
> Hat's patches or something in the kernel.org sources.
> 
> Thanks again for the post!


<---More from a different response follows--->


Alright...an answer from someone that works at RedHat:

> Ran it past some folks in development. I'm paraphrasing much of their
> responses. Feel free to pass this back to where you originally saw it.
> 
> > > A few reasons:
> > > 
> > > - - UTF-8 by default throughout the OS, including in the boot scripts;
> > > this
> > >   means odd and/or non-optimized collation rules etc. make sure you set
> > > "LANG=C" instead of "LANG=en_US.utf8".
> 
> LANG=C is a bad idea. What they want is LANG=en_US.ISO-8859-1 (our
> previous default).
> 
> LANG=C isn't 8-bit clean basically, while the Latin-1 locales are.
> Non-ASCII chars are considered "invalid" in LANG=C.
> 
> As for UTF-8, people are certainly free to run in whatever encoding
> they want, and it's one config file to change, but it's just
> hiding their head in the sand and pretending that the rest of the
> world doesn't exist. Plus, if we never converted to UTF-8, we'd
> never have found out what needed to be optimized.
> 
> Fedora Core 1 includes substantial optimizations to some of the system
> tools for operation in UTF-8 mode.
> 
> > > - - some horrible wchar_t patches applied to various things.  The RH9
> > >   version of Tcl/Tk, for example, uses 4x the RAM for text areas, due to
> > > a patch that makes them use wchar_t instead of char.   This
> > > *massively* screws up most useful Tk apps, like ExMH.
> 
> This is generally true.  UTF-8 support has been added as an
> afterthought to lots of text processing applications, and
> unfortunately no thought seems to have been given to efficiency in
> lots of cases.  An extreme example is grep: see bugzilla #69900.  Red
> Hat have reported a lot of these cases upstream, with a start at fixing
> it, to seemingly deaf ears.
> 
> There was an overwhelming consensus that people unhappy with things
> should post their issues to the Fedora mailing lists and help us get
> them resolved. Remember, Red Hat is not consciously trying to break and
> maim Linux. ;)

-- 
Justin Keyes             twitch ---at--- port0 ---dot--- net

Americans have come to believe that congress can do anything 
that is wonderful; anything that has a majority vote.
--Walter Williams



More information about the linux-elitists mailing list