Port-arm archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RPi performance issue, pmap to blame?
(2013/11/21 23:55), Reinoud Zandijk wrote:
Dear folks,
as some of you might have heared of, i am trying to get an RPi to do some
(image) processing task for me but i run into various odd behaviour. For one,
can someone reproduce this?
When i run pkgsrc's ImageMagick's `convert' on a bigger image, say a
'PNG image data, 2135 x 3230, 8-bit/color RGB, non-interlaced', and try to
scale/rotate/whatever it, the memory usage gets into the 200 Mb eventually.
I know the RPi isn't the fastest beast around, but what struck me is that most
of the time is spend in system-time! A convert process can easy show:
load: 0.99 cmd: convert 12662 [0x401cdec4] 24.72u 109.17s 32% 387220k
Note this is a 512 Mb RPi and there is still tens of Mb marked free so no
swapping is going on.
When running, i do get an occasional "pglistalloc waiting", but not that
often.
Looking at the vmstat's some things struck me:
---------------
rpi# vmstat -e
event total rate type
vmcmd kills 261793 1 misc
vmcmd extends 205133 1 misc
vmcmd calls 2642394 16 misc
deferred intr 249909 1 misc
pmap prefer nochange 3690430 22 misc
pmap prefer change 1 0 misc
pmap activations 35933461 218 misc
pmap updates 105661119 641 misc
pmap exec pages discarded (DG) 186 0 misc
pmap exec pages discarded (PP) 1459118 8 misc
pmap exec pages discarded (UM) 1559175 9 misc
pmap exec pages synced (KU) 52 0 misc
pmap exec pages synced (DG) 6265 0 misc
pmap exec pages synced (RM) 6567285 39 misc
pmap exec pages synced (UM) 11858 0 misc
pmap exec pages synced (MP) 554171 3 misc
pmap exec pages synced 7139631 43 misc
pmap exec pages mapped 97736514 593 misc
pmap page table pages mapped 48 0 misc
pmap kenter pages unmapped 3235883 19 misc
pmap kenter pages mapped 4445491 26 misc
pmap kernel pages unmapped 4666961 28 misc
pmap kernel pages mapped 4669134 28 misc
pmap pages remapped 6576304 39 misc
pmap pages unmapped 157372322 955 misc
pmap pages mapped 157428664 955 misc
pmap new page color 93597 0 misc
vmemev bt_inuse 730 0 misc
vmemev bt_count 1806 0 misc
vmemev bt_pages 11 0 misc
cpu0 undefined insn traps 509649 3 trap
pdpolicy reactanon 153647 0 misc
pdpolicy reactexec 54758 0 misc
softint net/0 4979224 30 misc
softint net block/0 1301 0 misc
softint clk/0 7611963 46 misc
softint clk block/0 13 0 misc
softint ser/0 10885527 66 misc
callout late/0 27 0 misc
crosscall unicast 2 0 misc
crosscall broadcast 113 0 misc
namecache entries scanned 399069 2 misc
namecache entries collected 1817826 11 misc
namecache over scan target 394 0 misc
namecache under scan target 164391 0 misc
namecache forced reclaims 388 0 misc
cpu0 translation abort (S) 2156860 13 trap
cpu0 translation abort (P) 45729671 277 trap
cpu0 domain abort (P) 4264 0 trap
cpu0 permission abort (P) 7362938 44 trap
VFP coproc use 326476 1 misc
VFP coproc re-use 183173 1 misc
bcm2835 pic uart 5334616 32 intr
bcm2835 pic emmc 28523984 173 intr
bcm2835 pic usb 1331781849 8084 intr
Accessing USB storage heavily?
bcm2835 pic timer3 16447834 99 intr
bcm2835 pic Doorbell0 3 0 intr
---------------
Note the exceptional high `pmap pages (un)mapped' rate as well as the `exec
pages mapped', the `pmap updates' and the high number of `cpu translation
abort (P)' rates.
What struck me was that those figures were also high when the machine was
idle!
The following questions pop into my mind reading the vmstats :
- Is there really only ONE page color?
- Aren't domains used for kernel/userland pages separation?
- Isn't there a pmap for each process? It looks like its rebuild over and over
again.
- Is the tlb really flushed on each system call? on each interrupt due to
this?
- What can cause this phenomenon other than a pmap issue?
---------------
rpi# vmstat -s
4096 bytes per page
1 page color
111091 pages managed
91054 pages free
8891 pages active
614 pages inactive
0 pages paging
1 pages wired
0 zero pages
1 reserve pagedaemon pages
5 reserve kernel pages
1595 anonymous pages
4848 cached file pages
3063 cached executable pages
256 minimum free pages
341 target free pages
37030 maximum wired pages
1 swap devices
32767 swap pages
1170 swap pages in use
660 swap allocations
64976590 total faults taken
84086976 traps
1383063735 device interrupts
70945103 CPU context switches
23496354 software interrupts
390464092 system calls
650 pagein requests
274 pageout requests
0 pages swapped in
4272 pages swapped out
391171 forks total
202471 forks blocked parent
202471 forks shared address space with parent
0 pagealloc zero wanted and avail
33465894 pagealloc zero wanted and not avail
0 aborts of idle page zeroing
43342463 pagealloc desired color avail
0 pagealloc desired color not avail
43342463 pagealloc local cpu avail
0 pagealloc local cpu not avail
80 faults with no memory
0 faults with no anons
8 faults had to wait on pages
0 faults found released page
423989 faults relock (423989 ok)
7149626 anon page faults
658 anon retry faults
5893120 amap copy faults
7322046 neighbour anon page faults
83451439 neighbour object page faults
23673137 locked pager get faults
423331 unlocked pager get faults
5032015 anon faults
2114109 anon copy on write faults
19507517 object faults
4165620 promote copy faults
33445352 promote zero fill faults
1412 times daemon wokeup
1394 revolutions of the clock hand
1556421 pages freed by daemon
1878659 pages scanned by daemon
4246 anonymous pages scanned by daemon
1552251 object pages scanned by daemon
15255 pages reactivated
98502 pages found busy by daemon
3998 total pending pageouts
1960227 pages deactivated
61741880 total name lookups
54159067 good hits
4306225 negative hits
291577 bad hits
18 false hits
2882911 miss
102082 too long
442788 pass2 hits
556258 2passes
cache hits (87% pos + 6% neg) system 0% per-process
deletions 0%, falsehits 0%, toolong 0%
------------
For completion, its a 512 Mb RPi :
uname -a:
NetBSD rpi 6.99.27 NetBSD 6.99.27 (RPI) #1: Tue Nov 19 14:10:25 CET 2013
reinoud%diablo.13thmonkey.org@localhost:/usr/sources/cvs.netbsd.org/src-clean/sys/arch/evbarm/compile/obj/RPI
evbarm
uname -p:
earmv6hf
Ideas anyone?
With regards,
Reinoud
--
-----------------------------------------------
SAITOH Masanobu (msaitoh%execsw.org@localhost
msaitoh%netbsd.org@localhost)
Home |
Main Index |
Thread Index |
Old Index