Bug 101660 - O_DIRECT seems to chew up (not release) a ton of memory
Summary: O_DIRECT seems to chew up (not release) a ton of memory
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 101028
TreeView+ depends on / blocked
 
Reported: 2003-08-05 11:28 UTC by Steve Dickson
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-08-06 16:25:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Meminfo before the start of the testing (727 bytes, text/plain)
2003-08-05 11:30 UTC, Steve Dickson
no flags Details
Meminfo after the testing (726 bytes, text/plain)
2003-08-05 11:31 UTC, Steve Dickson
no flags Details
meminfo after the umount (725 bytes, text/plain)
2003-08-05 11:31 UTC, Steve Dickson
no flags Details

Description Steve Dickson 2003-08-05 11:28:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
While doing NFS testing with the OraSim test suite, I
notice that all of the memory on the client machine was
being used up (which eventually caused swapping) and not
being released. This happens on NFS mounted filesystem
and locally mount ext3 filesystem.

At first I wasn't alarmed that the all of the system
memory was being used since the machine only had 512MB of
memory and I figured that was just a side effect of running
OraSim. But what did seem strange was once the tests were done
the memory was not being released. The only way to release it
was to unmount the filesystem.

              total:    used:    free:       shared:  buffers:    cached:
Start : Mem:  524255232 304726016 219529216   0       116555776   44355584
End   : Mem:  524255232 510078976  14176256   0        23855104  437854208
Umount: Mem:  524255232  64393216 459862016   0         7434240    6696960

Start : Swap: 1073700864     8192 1073692672
End   : Swap: 1073700864    12288 1073688576
Umount: Swap: 1073700864    12288 1073688576

Now maybe this is normal, and the memory will eventually be
release and re-used as needed... but I just sees strange that
one process doing O_DIRECT writes could chew up all the
system memory and then not release it...


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


How reproducible:
Always

Steps to Reproduce:
1.Run OraSim
2.umount filesystem
3.
    

Additional info:

Comment 1 Steve Dickson 2003-08-05 11:30:05 UTC
Created attachment 93399 [details]
Meminfo before the start of the testing

Comment 2 Steve Dickson 2003-08-05 11:31:09 UTC
Created attachment 93400 [details]
Meminfo after the testing

Comment 3 Steve Dickson 2003-08-05 11:31:53 UTC
Created attachment 93401 [details]
meminfo after the umount

Comment 4 Stephen Tweedie 2003-08-06 13:04:35 UTC
There are lots of possibilities here.  A leak is very very unlikely, because
those tend not to get cleaned up at unmount.

So one possibility is that you're not actually doing raw IO.  When OraSim
creates a file, the file is initially sparse (ie. no disk blocks are actually
allocated, the blocks get filled in on demand.)  As it writes to the file, we're
filling in those holes, but O_DIRECT is disabled for such writes because of
possible races: the kernel falls back to buffered writes and O_SYNC.

Are you letting OraSim create the files itself, or are you preallocating the
files with "dd < /dev/zero" beforehand?

Comment 5 Steve Dickson 2003-08-06 16:21:16 UTC
I was leting OraSim create the files

Comment 6 Stephen Tweedie 2003-08-06 16:25:54 UTC
Then that's expected behaviour.  If performance is crashing as a result, then
that's a VM problem which you should probably raise with Rik, as plain buffered
IO shouldn't bring the system to its knees!

Please try reproducing with pre-created files and reopen this bug if the
problems persist.


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