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
Bug 101660 - O_DIRECT seems to chew up (not release) a ton of memory
O_DIRECT seems to chew up (not release) a ton of memory
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
Depends On:
Blocks: 101028
  Show dependency treegraph
Reported: 2003-08-05 07:28 EDT by Steve Dickson
Modified: 2007-11-30 17:06 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-06 12:25:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Steve Dickson 2003-08-05 07:28:38 EDT
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:

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

Additional info:
Comment 1 Steve Dickson 2003-08-05 07:30:05 EDT
Created attachment 93399 [details]
Meminfo before the start of the testing
Comment 2 Steve Dickson 2003-08-05 07:31:09 EDT
Created attachment 93400 [details]
Meminfo after the testing
Comment 3 Steve Dickson 2003-08-05 07:31:53 EDT
Created attachment 93401 [details]
meminfo after the umount
Comment 4 Stephen Tweedie 2003-08-06 09:04:35 EDT
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 12:21:16 EDT
I was leting OraSim create the files
Comment 6 Stephen Tweedie 2003-08-06 12:25:54 EDT
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.