Linux disk cache going mad.

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
An00biS
Prole
Posts: 21
Joined: Thu Nov 13, 2008 9:55 am
Location: mapy.cz/?query=rajhrad

Linux disk cache going mad.

Post 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? :x 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
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: Linux disk cache going mad.

Post 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?
An00biS
Prole
Posts: 21
Joined: Thu Nov 13, 2008 9:55 am
Location: mapy.cz/?query=rajhrad

Re: Linux disk cache going mad.

Post 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
Test2

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
Test3

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
Test4

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
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: Linux disk cache going mad.

Post 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.
An00biS
Prole
Posts: 21
Joined: Thu Nov 13, 2008 9:55 am
Location: mapy.cz/?query=rajhrad

Re: Linux disk cache going mad.

Post 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? :shock:
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 :joker: 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
User avatar
leiradel
Party member
Posts: 184
Joined: Thu Mar 11, 2010 3:40 am
Location: Lisbon, Portugal

Re: Linux disk cache going mad.

Post 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.
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 8 guests