Red Hat Bugzilla – Bug 101660
O_DIRECT seems to chew up (not release) a ton of memory
Last modified: 2007-11-30 17:06:57 EST
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:
Created attachment 93399 [details] Meminfo before the start of the testing
Created attachment 93400 [details] Meminfo after the testing
Created attachment 93401 [details] meminfo after the umount
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?
I was leting OraSim create the files
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.