Page 1 of 1
Linux disk cache going mad.
Posted: Sun Sep 19, 2010 9:07 pm
by An00biS
Hello everybody,
I'm running LOVE on Fedora 13 and I'm experiencing a quite peculiar behaviour - massive usage of disk cache. Memory consumption of the LOVE process itself is minimal, but the amount of disk space mapped to the process is gigantic. Just check out these few tests I ran. I'm using recent hg source (compiled just a few minutes ago) and I've got a laptop with 1024MB RAM. The code snippets are the _complete_ main.lua files I used, the numbers represent virtual memory (VIRT) measured by htop.
No script: 37MB
Code: Select all
function love.draw()
love.graphics.rectangle("line",100,100,400,400);
end
202MB
Code: Select all
function love.load()
font = love.graphics.newFont(12);
end
465MB
Code: Select all
function love.load()
font10 = love.graphics.newFont(10)
font20 = love.graphics.newFont(20)
font30 = love.graphics.newFont(30)
end
966MB
My question is: What's going on in there?
What's LOVE peeking all the time? And why would it load anything in the second example? Really, I'd like to know what actions at LOVE's startup could possibly cause this. I'm out of ideas here. Scripts are tiny and fonts don't weight much, either.
Somebody enlight me, pls.
~An00biS
Re: Linux disk cache going mad.
Posted: Sun Sep 19, 2010 9:13 pm
by bartbes
Well, fonts are heavier than you might think, and actually if you do the math you'll see that the (465-202)*3+202 is almost 966. May I ask how you measured this, so I can test this myself?
Re: Linux disk cache going mad.
Posted: Sun Sep 19, 2010 10:17 pm
by An00biS
bartbes wrote:...fonts are heavier than you might think
What do you mean? I checked out the fonts on my system and none had more than 1MB
bartbes wrote:May I ask how you measured this...?
I just ran "love game_dir" on the console and htop on the other. Note that the numbers represent disk cache which gets counted into virtual memory (VIRT collumn). Here are complete data from /proc/[pid]
Test1
Code: Select all
[an00bis@hpnx6310 12623]$ cat status
Name: love
State: S (sleeping)
Tgid: 12623
Pid: 12623
PPid: 4815
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
Utrace: 0
FDSize: 256
Groups: 500
VmPeak: 46840 kB
VmSize: 42744 kB
VmLck: 0 kB
VmHWM: 13616 kB
VmRSS: 13616 kB
VmData: 26372 kB
VmStk: 136 kB
VmExe: 1116 kB
VmLib: 12672 kB
VmPTE: 92 kB
VmSwap: 0 kB
Threads: 2
SigQ: 0/7862
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180004002
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: 3
Cpus_allowed_list: 0-1
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 191678
nonvoluntary_ctxt_switches: 67245
[an00bis@hpnx6310 12623]$ cat io
rchar: 6961372
wchar: 2524584
syscr: 210494
syscw: 84050
read_bytes: 1961984
write_bytes: 0
cancelled_write_bytes: 0
Code: Select all
[an00bis@hpnx6310 12697]$ cat status
Name: love
State: S (sleeping)
Tgid: 12697
Pid: 12697
PPid: 4815
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
Utrace: 0
FDSize: 256
Groups: 500
VmPeak: 207012 kB
VmSize: 207012 kB
VmLck: 0 kB
VmHWM: 10400 kB
VmRSS: 10400 kB
VmData: 56012 kB
VmStk: 136 kB
VmExe: 1116 kB
VmLib: 16076 kB
VmPTE: 128 kB
VmSwap: 0 kB
Threads: 5
SigQ: 0/7862
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180004002
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: 3
Cpus_allowed_list: 0-1
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 7526
nonvoluntary_ctxt_switches: 221
[an00bis@hpnx6310 12697]$ cat io
rchar: 1657376
wchar: 134331
syscr: 11591
syscw: 4328
read_bytes: 847872
write_bytes: 0
cancelled_write_bytes: 0
Code: Select all
[an00bis@hpnx6310 12718]$ cat status
Name: love
State: S (sleeping)
Tgid: 12718
Pid: 12718
PPid: 4815
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
Utrace: 0
FDSize: 256
Groups: 500
VmPeak: 467704 kB
VmSize: 207608 kB
VmLck: 0 kB
VmHWM: 11104 kB
VmRSS: 11104 kB
VmData: 56608 kB
VmStk: 136 kB
VmExe: 1116 kB
VmLib: 16076 kB
VmPTE: 380 kB
VmSwap: 0 kB
Threads: 5
SigQ: 0/7862
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180004002
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: 3
Cpus_allowed_list: 0-1
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 8135
nonvoluntary_ctxt_switches: 170
[an00bis@hpnx6310 12718]$ cat io
rchar: 1613559
wchar: 111583
syscr: 10231
syscw: 3568
read_bytes: 135168
write_bytes: 0
cancelled_write_bytes: 0
Code: Select all
[an00bis@hpnx6310 12738]$ cat status
Name: love
State: S (sleeping)
Tgid: 12738
Pid: 12738
PPid: 4815
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
Utrace: 0
FDSize: 256
Groups: 500
VmPeak: 991228 kB
VmSize: 210940 kB
VmLck: 0 kB
VmHWM: 12396 kB
VmRSS: 6716 kB
VmData: 59940 kB
VmStk: 136 kB
VmExe: 1116 kB
VmLib: 16076 kB
VmPTE: 892 kB
VmSwap: 3828 kB
Threads: 5
SigQ: 0/7862
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180004002
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: 3
Cpus_allowed_list: 0-1
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 69120
nonvoluntary_ctxt_switches: 1158
[an00bis@hpnx6310 12738]$ cat io
rchar: 3298562
wchar: 848163
syscr: 72183
syscw: 28162
read_bytes: 15335424
write_bytes: 0
cancelled_write_bytes: 0
~An00biS
Re: Linux disk cache going mad.
Posted: Sun Sep 19, 2010 11:00 pm
by bartbes
I don't get numbers nearly as big, weird, is this the same with previous versions?
About the fonts, well, the files aren't too big, but they are prerendered, so that can add up.
Re: Linux disk cache going mad.
Posted: Mon Sep 20, 2010 9:43 pm
by An00biS
bartbes wrote:... is this the same with previous versions?
Dunno, I've only used two recent hg sources, the official source tarball didn't compile for me (build script error).
bartbes wrote:About the fonts... they are prerendered
Really?
Why is that so? Is it the performance of rendering itself, or something else? Because I've worked SDL_ttf before (uses FreeType), I rendered with anti-aliasing and alpha and it worked fast enough. So' I don't think pre-rendering is the way to go, at least not if it can't be disabled. IMHO it would be better to let user render texts as images and blit them as so.
Edit: Now that I think of it, pre-rendered fonts aren't the problem unless LOVE swaps them to disk
The /proc reports make it clear that actual application data in the RAM are quite small.
Direct question: are you sure there are no files being mistakenly left open at startup?
~An00biS
Re: Linux disk cache going mad.
Posted: Wed Sep 22, 2010 8:56 pm
by leiradel
An00biS wrote:Because I've worked SDL_ttf before (uses FreeType), I rendered with anti-aliasing and alpha and it worked fast enough.
SDL_ttf caches rendered glyphs to improve rendering performance.