Bug 65063

Summary:	(VM)Kernel VM/swap so bad it is nearly unusable
Product:	[Retired] Red Hat Linux	Reporter:	Erich Boleyn <erich>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	gedetil, pfrields, sysadmin, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-01-05 04:29:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Erich Boleyn 2002-05-16 22:00:28 UTC

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:
Always

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.
3.


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 16:48:34 UTC

This sounds quite similar to what was already reported in bug # 60079 and bug #
61007.
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 17:48:00 UTC

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 17:55:19 UTC

Actually, I should be more specific.  It pages things in slowly under ANY write
load.

Comment 4 Arjan van de Ven 2002-05-20 19:23:43 UTC

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-05 04:29:03 UTC

Closing (end of lifed).
Latest errata kernels have various fixes in this area btw