IO Subsumption og trådning af Java
Dato:
|
4 Mar 2014
|
Varighed:
|
8 timer
|
Status
Robotten er næsten færdig: IO Subsumption mangler at blive trådet.
Mål
Gør arbejdet med IO Subsumption trådet, så robotten er "færdig".
Undersøg og eksperimenter med trådning af java's Thread (igennem den installerede JVM) på maskinen.
Trådning af robotten
Robottens IO adfærd er kodet om til at benytte 1 tråd pr adfærd. desværre ser det ud til at robotten ikke kan lide dette. Der er alvorlige timing-problemer ift. skifte imellem adfærd. Dette må undersøges næste lab.
Herunder kan ses præcis hvad problemet er ift. robottens adfærd (som burde være "identisk" med leJOS-implementationen):
En umiddelbar tanke ift. at få undersøgt om det helt konkret er trådningen eller fejlagtig konvertering af adfærd, ville være at implementere alle opdateringer af motor-forspøgelser i en enkelt tråd. Jeg må vende tilbage for at vurdere hvordan jeg bedst afdækker udfordringen og giver et svar på problemet ovenfor.
Herunder kan ses præcis hvad problemet er ift. robottens adfærd (som burde være "identisk" med leJOS-implementationen):
En umiddelbar tanke ift. at få undersøgt om det helt konkret er trådningen eller fejlagtig konvertering af adfærd, ville være at implementere alle opdateringer af motor-forspøgelser i en enkelt tråd. Jeg må vende tilbage for at vurdere hvordan jeg bedst afdækker udfordringen og giver et svar på problemet ovenfor.
Undersøgelse af trådningens effekt
For at finde ud af hvordan trådene faktisk fungerer, har jeg startet med at tage et hurtigt kig på hvilken software jeg har at arbejde med. Grunden til at dette er så relevant er, at jeg ikke inden undersøgelsen var sikker på hvordan maskinens JVM faktisk håndterede tråde, og dokumentationen fra oracle gør der tydeligt at dette kun gælder for deres Hotspot. EV3 bruger en anden JVM (ejre-7u40-fcs-b43-linux-arm-sflt-headless-27_aug_2013), som jeg hidtil har antaget virker på nogenlunde samme måde som Hotspot, ift. afvikling af java-kode. Nu er det på tide at finde ud af om denne JVM blot er en headless Hotspot.
Ligeledes faldt jeg over en diskussion[1] på stackoverflow om hvordan tråde er mapped fra Java til OS. Jeg vil herunder afdække, empirisk, hvorvidt min EV3 bruger Native eller Green Threads.
System info
Kernel: 2.6.33-rc4 (released on February 24th, 2010 [2])Busybox: v1.13.2 (2010-12-21 19:28:47 CST) multi-call binary
Betydning for undersøgelsen
Busybox er en fin ide til at begrænse forbruget af ressourcer på et system. Desværre for mig, understøtter den forholdsvis gamle version ingen af de gængse måder at overvåge cpu-forbrug (top / ps, med argumenter). Eller rettere, de programmer er kun understøttet i så begrænset omfang, at jeg ikke kan se tråde.
Selve undersøgelsen
Da de "lette" kommandoer ikke er til rådighed, blev jeg nødsat til at tilgå informationen direkte. Derfor vil der herunder være lettere kryptiske udskrifter, som jeg forklarer og gennemgår til sidst. Kommentare er skrevet i [], hvis jeg har ændret på udskrift eller for at forklare hvad jeg laver med mit java-program.
root@EV3:~# top
Mem: 59084K used, 1820K free, 0K shrd, 1612K buff, 30324K cached
CPU: 89% usr 8% sys 0% nic 0% idle 0% io 0% irq 1% sirq
Load average: 1.23 0.75 1.01 2/87 1503
PID PPID USER STAT VSZ %MEM %CPU COMMAND
1487 1356 root S 171m 288% 88% /home/root/lejos/ejre1.7.0_51/bin/[...]
[fjernet resten, dette er mit program/min process]
root@EV3:~# cat /proc/sys/kernel/threads-max
949
[java-programmet kører med 1 aktiv tråd og 0 ekstra tråde]
root@EV3:~# cat /proc/1487/status
Name: java
State: S (sleeping)
Tgid: 1487
Pid: 1487
PPid: 1356
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 1024
Groups:
VmPeak: 176648 kB
VmSize: 175764 kB
VmLck: 0 kB
VmHWM: 14264 kB
VmRSS: 14264 kB
VmData: 153384 kB
VmStk: 84 kB
VmExe: 4 kB
VmLib: 12760 kB
VmPTE: 50 kB
Threads: 10
SigQ: 0/474
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000004
SigIgn: 0000000000000000
SigCgt: 2000000181005ccf
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 2
nonvoluntary_ctxt_switches: 145
[java-programmet kører med 1 aktiv tråd og 5 ekstra tråde]
root@EV3:~# cat /proc/1487/status
Name: java
State: S (sleeping)
Tgid: 1487
Pid: 1487
PPid: 1356
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 1024
Groups:
VmPeak: 177384 kB
VmSize: 177364 kB
VmLck: 0 kB
VmHWM: 14428 kB
VmRSS: 14428 kB
VmData: 154984 kB
VmStk: 84 kB
VmExe: 4 kB
VmLib: 12760 kB
VmPTE: 52 kB
Threads: 15
SigQ: 0/474
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000004
SigIgn: 0000000000000000
SigCgt: 2000000181005ccf
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 2
nonvoluntary_ctxt_switches: 145
[java-programmet kører med 1 aktiv tråd og 10 ekstra tråde]
root@EV3:~# cat /proc/1487/status
Name: java
State: S (sleeping)
Tgid: 1487
Pid: 1487
PPid: 1356
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 1024
Groups:
VmPeak: 179116 kB
VmSize: 179096 kB
VmLck: 0 kB
VmHWM: 14520 kB
VmRSS: 14520 kB
VmData: 156716 kB
VmStk: 84 kB
VmExe: 4 kB
VmLib: 12760 kB
VmPTE: 52 kB
Threads: 20
SigQ: 0/474
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000004
SigIgn: 0000000000000000
SigCgt: 2000000181005ccf
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 2
nonvoluntary_ctxt_switches: 145
[java-programmet kører med 1 aktiv tråd og 15 ekstra tråde]
root@EV3:~# cat /proc/1487/status
Name: java
State: S (sleeping)
Tgid: 1487
Pid: 1487
PPid: 1356
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 1024
Groups:
VmPeak: 180716 kB
VmSize: 180696 kB
VmLck: 0 kB
VmHWM: 14616 kB
VmRSS: 14616 kB
VmData: 158316 kB
VmStk: 84 kB
VmExe: 4 kB
VmLib: 12760 kB
VmPTE: 54 kB
Threads: 25
SigQ: 0/474
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000004
SigIgn: 0000000000000000
SigCgt: 2000000181005ccf
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 2
nonvoluntary_ctxt_switches: 145
[java-programmet kører med 1 aktiv tråd og 25 ekstra tråde]
root@EV3:~# cat /proc/1487/status
Name: java
State: S (sleeping)
Tgid: 1487
Pid: 1487
PPid: 1356
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 1024
Groups:
VmPeak: 183916 kB
VmSize: 183896 kB
VmLck: 0 kB
VmHWM: 14800 kB
VmRSS: 14800 kB
VmData: 161516 kB
VmStk: 84 kB
VmExe: 4 kB
VmLib: 12760 kB
VmPTE: 58 kB
Threads: 35
SigQ: 0/474
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000004
SigIgn: 0000000000000000
SigCgt: 2000000181005ccf
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 2
nonvoluntary_ctxt_switches: 145
[java-programmet kører med 1 aktiv tråd og 0 ekstra tråde, ventede 1 min for at være sikker på garbage collection ol.]
root@EV3:~# cat /proc/1487/status
Name: java
State: S (sleeping)
Tgid: 1487
Pid: 1487
PPid: 1356
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 1024
Groups:
VmPeak: 183916 kB
VmSize: 183896 kB
VmLck: 0 kB
VmHWM: 14824 kB
VmRSS: 14824 kB
VmData: 161516 kB
VmStk: 84 kB
VmExe: 4 kB
VmLib: 12760 kB
VmPTE: 58 kB
Threads: 10
SigQ: 0/474
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000004
SigIgn: 0000000000000000
SigCgt: 2000000181005ccf
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 2
nonvoluntary_ctxt_switches: 145
Jeg har markeret den signifikante information med fed skrift. For hver ekstra java-thread jeg startede, blev der forbrugt endnu 1 native thread. Ved hver nedlagte java-thread blev der (med passende ventetid) nedlagt 1 native thread. Dette tager jeg som bevis for at Java til OS mapping af tråde er 1:1 (altså ligesom for Hotspot).
Ligeledes er det interessant at bemærke, at systemet maksimalt kan håndtere 949 tråde for alle processer. Denne øvre grænse er noget højere end jeg antog inden undersøgelsen begyndt.
Eftersom hver java-tråd er mapped til en native tråd, betyder det også at det er OS der står for schedueling af trådene. Denne schedueling KAN være anderledes end Round-Robin, som blev brugt at java's Green Threads i version 1.1, men ved den kernel jeg har på min EV3 benyttes Round-Robin dog også - havde min kernel været nutidig, ville den have brugt Completely Fair Schedueling (CFS) i stedet. Dette er en relevant ting at huske, særligt hvis leJOS beslutter sig for at opdatere deres system på et tidspunkt (hvilket man kunne håbe på, ud fra de datoer jeg har skrevet ovenfor... =).
Besynderligt nok så står programmet til at have status S (sleeping), på trods af at det kører og beregner primtal. Jeg har intet bud på hvorfor denne state ikke er sat til R (ready/running).
Her er lidt mere om de pthreads der er talt ovenfor:
http://man7.org/linux/man-pages/man7/pthreads.7.html
Her er lidt mere om de pthreads der er talt ovenfor:
http://man7.org/linux/man-pages/man7/pthreads.7.html
Refs
1. http://programmers.stackexchange.com/questions/120384/why-not-green-threads
2. http://kernelnewbies.org/Linux_2_6_33
No comments:
Post a Comment