Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
First Last Prev Next    This bug is not in your last search results.
Bug 54176 - [performance/VM] Slow application startup
[performance/VM] Slow application startup
Status: CLOSED NOTABUG
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ed McKenzie
Brock Organ
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2001-09-30 10:53 EDT by Ed McKenzie
Modified: 2007-04-18 12:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-01 13:19:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Ed McKenzie 2001-09-30 10:53:40 EDT 
Graphical applications are slow to start on a K6-2/400 running
kernel-2.4.9-0.5.  By comparison, starting gedit, emacs or gnumeric is
almost instantaneous on the same box running FreeBSD 4.4.  I have 384MB of
RAM, so this isn't a thrashing issue -- things are slow even when launching
cached applications and no swap is being used.

The performance problem could be in glibc and not the kernel.  I don't know
enough to say for sure.
Comment 1 Arjan van de Ven 2001-09-30 11:04:01 EDT 
Be advised that the 2.4.9-0.5 kernel has quite a few debugging options enabled,
such as slab poison. Comparisons with production compiled kernels is hence
dangerous....
Comment 2 Ed McKenzie 2001-09-30 11:17:13 EDT 
Mea culpa.  I'll build the latest -ac with a non-debug config and try again.
Comment 3 Ed McKenzie 2001-10-01 00:14:30 EDT 
Ok, tested with 2.4.9-0.5custom and debug options off.  Subjectively, it does
seem faster than with debugging on, but it's still quite a bit slower than
FreeBSD.  I'm going to do some more profiling on both platforms and report back
here.
Comment 4 Arjan van de Ven 2001-10-01 04:28:20 EDT 
Does typing

echo 511 > /proc/sys/vm/max-readahead

help ?
Comment 5 Ed McKenzie 2001-10-01 13:19:34 EDT 
It made a slight difference, but over ten runs it was small enough that I don't
think it's statistically significant.
Comment 6 Ed McKenzie 2001-10-05 01:13:57 EDT 
Closing bug -- user error.  Too much RAM on a cheap motherboard favors FreeBSD,
as Linux allocates memory top-to-bottom and winds up running out of uncached memory.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.