Closed GoogleCodeExporter closed 9 years ago
not surprising at all.
a value of 512MB for *imagemaxmb= is insane because the kernel only has a 256MB
virtual memory window. the real problem is that the cpu kernel uses a heuristic
that
limits kernel memory to a fixed amount (64MB + size of page tables). note that
image memory is within that space! this will be enougth for a few rio windows,
but is not practical for graphics heavy stuff. as a work around, i disabled
that heuristic now (see commit r49af4f09cf64) when *imagemaxmb= is specified.
Original comment by cinap_le...@felloff.net
on 2 Aug 2013 at 2:04
i updated kernel & all to get the change, and set a more reasonable
*imagemaxmb=128, but this has made no difference. image memory is still capped
at 68.4MB exactly as before the changes.
cpu% cat /dev/swap
2064351232 memory
4096 pagesize
30196 kernel
125929/473796 user
0/160000 swap
19010080/71750016 kernel malloc
49697920/71750016 kernel draw
cpu% hoc
71750016/1024^2
68.4261474609
Original comment by tereniao...@gmail.com
on 10 Aug 2013 at 2:17
i'v tested this change and it works.
if(cpuserver) {
if(userpcnt < 10)
userpcnt = 70;
kpages = conf.npage - (conf.npage*userpcnt)/100;
/*
* Hack for the big boys. Only good while physmem < 4GB.
* Give the kernel fixed max + enough to allocate the
* page pool.
* This is an overestimate as conf.upages < conf.npages.
* The patch of nimage is a band-aid, scanning the whole
* page list in imagereclaim just takes too long.
*/
>> if(getconf("*imagemaxmb") == 0)
if(kpages > (64*MB + conf.npage*sizeof(Page))/BY2PG){
kpages = (64*MB + conf.npage*sizeof(Page))/BY2PG;
conf.nimage = 2000;
kpages += (conf.nproc*KSTACK)/BY2PG;
}
} else {
the >> marked line is the one that allows the same kernel/user split allocation
like with the terminal kernel. please make really sure this is the effective
code you'r using. add a debug print in that routine to make sure thats the
actual code you'r using.
Original comment by cinap_le...@felloff.net
on 25 Aug 2013 at 7:53
Aye, my mistake. My new-kernel script wasn't building the kernel before
install. I fixed that, and tested by setting *imagemaxmb=192 and opening a lot
of gifs in separate windows. Used draw memory was then 191MB, which is close
enough for me. Thanks!
Original comment by tereniao...@gmail.com
on 26 Aug 2013 at 1:05
Original issue reported on code.google.com by
tereniao...@gmail.com
on 30 Jul 2013 at 5:59