Bug 65063 - (VM)Kernel VM/swap so bad it is nearly unusable
(VM)Kernel VM/swap so bad it is nearly unusable
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-05-16 18:00 EDT by Erich Boleyn
Modified: 2015-01-04 17:01 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-04 23:29:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Erich Boleyn 2002-05-16 18:00:28 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510

Description of problem:
It functions as far as I can tell, but as long as swap space is turned on, it
seems to swap rather than reclaim pages from the file cache.  This very quickly
causes the machine to become unusable when large files are copied or written. 
The program which caused the problem was not always killable due to the
interactive X windows being badly swapped out.

More precisely, I suppose this is a problem with the kernel having a policy of
treating file write data as higher priority (or even the same priority) as
program text/data.

As far as I'm concerned, swap is broken in this kernel version.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Copy/FTP a huge file or set of files onto the machine which are larger than
the system's RAM.
2.  Try to run some interactive programs.

Actual Results:  The machine quickly throws out all it's working sets and gets
mired swapping.

Sometimes it was so bad, the interactive shells and/or X windows were swapped
out and would *NOT* come back.  This is bad.

Expected Results:  It should have been writing out the file data and not
throwing out the working sets of programs.

Additional info:
Comment 1 Gilbert E. Detillieux 2002-05-17 12:48:34 EDT
This sounds quite similar to what was already reported in bug # 60079 and bug #
Funny thing is, the former bug report suggests the problem was resolved in the
rawhide kernel update,
but the kernel update issued for 7.3 should be newer than that bug report.
Comment 2 Erich Boleyn 2002-05-17 13:48:00 EDT
Hmm.  Further testing shows I was smoking something.

It appears what I really saw was the I/O layer paging things in very slowly
under high write load.
Comment 3 Erich Boleyn 2002-05-17 13:55:19 EDT
Actually, I should be more specific.  It pages things in slowly under ANY write
Comment 4 Arjan van de Ven 2002-05-20 15:23:43 EDT
it might be worthwhile to check if "elvtune" can improve this.
elvtune can be used to reduce the read and write latency parameters;
basically larger values for those mean more aggressive reordering of
io requests, which can result in longer latencies and starvation.
Comment 5 Dave Jones 2004-01-04 23:29:03 EST
Closing (end of lifed).
Latest errata kernels have various fixes in this area btw

Note You need to log in before you can comment on or make changes to this bug.