konqy preloading kills performance

[Lubos Lunak]

On Wednesday 15 of December 2004 21:07, Dario Massarin wrote:
> On Wednesday 15 December 2004 12:25, Lubos Lunak wrote:
> >  Hmm :(. Could you please have a closer look at current_memory_usage() in
> > konqueror/konq_mainwindow.cc and check what exactly it does when it
> > reports this low value? Also, the Linux memory check uses
> > /proc/<pid>/statm, not status, so contents of that could be useful as
> > well.
>
> It seems that konqueror the current_memory_usage() function returns exactly
> what it should:
>
> #konqueror </dev/null 2>&1 | tee logfile2.txt
>
> #cat logfile2.txt | grep Memory
> konqueror: Memory usage increase: 7271424 (15493120/8221696)
>
> #cat logfile2.txt | grep preload
> konqueror: Konqy kept for preloading :konqueror-6740
>
> #cat /proc/6740/statm
> 14944 10860 8550 2 0 14942 0
>
> Here the first number is only a bit different from the one that konqueror
> reads when the current_memory_usage() functions gets called. I think this
> is normal becouse I execute the above command in a different time.
> Maybe the problem resides on the fact that using this data to know the
> current memory usage is not completely correct.
> Reading   /usr/src/linux/Documentation/filesystems/proc.txt  I found a
> little (and too little for my taste) explanation of the output of statm:
>
> Table 1-2: Contents of the statm files
> ...........................................................................
>... File			Content
>  size        		total program size
>  resident		size of memory portions
>  shared		number of pages that are shared
>  trs			number of pages that are 'code'
>  drs			number of pages of data/stack
>  lrs			number of pages of library
>  dt			number of dirty pages

 Actually, my kernel (SUSE 2.6.8-24.3-default) has better documentation:

Table 1-2: Contents of the statm files (as of 2.6.8-rc3)
..............................................................................
 Field    Content
 size     total program size (pages)            (same as VmSize in status)
 resident size of memory portions (pages)       (same as VmRSS in status)
 shared   number of pages that are shared       (i.e. backed by a file)
 trs      number of pages that are 'code'       (not including libs; broken,
                                                        includes data segment)
 lrs      number of pages of library            (always 0 on 2.6)
 drs      number of pages of data/stack         (including libs; broken,
                                                        includes library text)
 dt       number of dirty pages                 (always 0 on 2.6)
..............................................................................

 This makes the mistake obvious - the size is in pages.

> mapped:   59780 KB writable/private: 26792 KB shared: 1072 KB

 14944 * 4096 / 1024 ~= 59780

> I really don't know why there is such a gap. But since we know that there
> is this problem, what about setting the memory thereshold from 16Mbytes to
> 8 Mbytes?

 Doing arbitrary changes to thresholds to fix unknown problems is not a very 
good idea. But now that the problem is know, changes are needed of course.

> Or better make a thereshold that depends on the current amount of ram.
> Something like:
> Ram					Thereshold
> 512Mb or higher		16Mb
> 256Mb				8Mb
> 128Mb				4Mb

 Exceeding the 8M threshold is actually trivial, after multiplying the current 
values by 4 - e.g. viewing dot.kde.org does the job. The /proc method uses 
complete memory usage of the process, including shared memory taken by 
libraries etc. , and the initial increase is large. In fact the 8M threshold 
is almost reached even by just showing empty Konqueror window and closing it, 
it seems there's a lot of delayed initialization going on.

 I'll fix the usage computation and backport it, and I'll change the threshold 
to let's say 20M, in order to avoid the current real threshold of 64M. If 
somebody feels like improving it e.g. to detect all memory available and keep 
this low limit only for old machines, feel free to.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/