Open GoogleCodeExporter opened 9 years ago
Bom kar prilepil odgovor na Gašperjev mail, da razložim kaj je problem te
commitane
kode:
Fora je v tem da funkcija "register_timer" ubistvu naredi naslednje (podana sta
mu
dva parametra in sicer št. period - jiffies - zakasnitve in pointer na TCB
procesa):
* Zgenerira novo timer strukturo in jo vstavi na ustrezno mesto v
prioritetni vrsti, glede na to koliko časa mora še preteči do prožitve
timerja.
Vsako milisekundo pa se kliče prekinitveni handler "timer_irq_handler", ki
naredi naslednje:
* Ob prekinitvi se poveča jiffies counter, ki predstavlja število period
od
zagona sistema. Nato se preveri ali lahko sprožimo prvi timer v vrsti. V
kolikor ga lahko, se zbudi prvi task in preveri ali lahko sprožimo tudi
naslednjega (in tako naprej, ker so taski v sortirani prioritetni vrsti).
Torej "timers.s" že implementirajo možnost delaya več taskov (zato je tudi
trenutna implementacija svc_delay tako kratka, ker je večina kode tam v
timers.s). Torej ubistvu bi vi morali zamenjati tiste funkcije, ki so
trenutno v timers.s (eno je registracija timerja, drugo pa prekinitvena
rutina ki se proži na vsako milisekundo).
Original comment by kos...@gmail.com
on 29 Nov 2008 at 11:06
no, in zakaj bi to delali, če je že narejeno? :P
updateal sem wiki:README in TODO.
Voljno. :)
Original comment by jernej.kernc@gmail.com
on 29 Nov 2008 at 12:37
Sej mi lohk kr rasper pravte ;)
Ma ja, to nam je tkrt profesor povedal kako nej bi naredil rešitev za hkratno
štetje
več delay-ev z enim timer-jem in mi smo pol tisto naredil, timer smo pa
pogledal sam
tolk, kej prejema kot parametre, neč kej preveč podrobno, ker smo mislili, da
je pač
navadn timer, ki ko prešteje vrednost samo postavi zastavco TWAIT na 0...tko
da pol
smo vbistvu nardil nekaj podobnga kot je v timerju, samo na drugačen
način...drugače
bi imel mi skoraj nič dela (samo posredovat podatke timerju in postavt
zastavico
TWAIT), pa to je tud že itak napisan v trunk-u, tko da pol res ne vem, kako si
je
profesor zamislu to...
V skupini smo pa: Gašper Rupnik, Anže Pečar, Tomaž Sečnik, Erik Hribar
Original comment by gasper.r...@gmail.com
on 29 Nov 2008 at 2:34
No, mi bi radi da bi se commital našo kodo tud v trunk - zadeva (delay)
preverjeno
deluje -> trenutno so testni primeri narejeni tako, da lučke prižiga, ko task
nekaj
dela in lučke ugaša, ko je task v 'delay-u' ... v končni verziji bo moralo to
delovati tako, da se bo na terminal izpisovalo, kaj določen task dela...mi tega
trenutno ne moremo še realizirat, ker skupina ki je zadolžena za to, to še ni
naredila -> ko bo, bo to trivialno popravit -> samo spremeniti kodo v tasku.
Sam sistemski klic pa deluje!
Spremenili smo kodo:
- 'syscall.s' // pri svc_delay smo dodali skok za našo kodo
- 'svc_delay.s' // to smo dodali v naš projekt (koda za sistemski klic)
- 'timers.s' // sprememba celotne kode
- dodali smo 4 taske v 'src/tasks'
- 'include/space.s' // dodali delaylist strukturo in vse potrebno za naše
štiri taske
- 'include/structures.s' // dodali konstante
- 'include/globals.s' // dodali globalni spremenljivki CDLYTCB, DLYLIST in
spremenili
MAXTASK
- in še v link file (config/layout.ind) smo dodali vse potrebno za naše
štiri dodatne
taske.
To je več al manj vse (koda je v branches/group3)
LpG
Original comment by gasper.r...@gmail.com
on 18 Dec 2008 at 10:17
Nekaj komentarjev na strukturo kode:
* Fino bi bilo, če bi bila koda v datoteki timers.s in ne v ločeni datoteki
svc_delay.s
* Prav tako bi bilo boljše, če se pri sistemskem klicu izognemo dodatnemu branchu,
trenutno je namreč (vrstica 74):
svc_delay:
/* Jump to delay */
b dl_arfd
Rešitev je seveda da se v tabelo sistemskih klicev doda neposredno dl_arfd.
* Krajšanje imen (samo začetne črke besed) label velja samo za _notranje_ labele v
funkcijah. Imena samih funkcij naj bodo raje nekaj v stilu
timers_register/timers_unregister ipd.
* V repozitorij ste commitali datoteke, ki niso potrebne za prevajanje kode in
sicer so to naslednje:
group3/project/lbos-fri.lbos-fri.elf.slo
group3/project/Progress.log
group3/project/sample.map
group3/project/Debug [celoten imenik]
group3/config/___Lnk.ind
Te datoteke odstranite iz repozitorija.
Toliko na hitro z moje strani, vsebinski review kode pa še sledi.
Original comment by kos...@gmail.com
on 18 Dec 2008 at 11:40
Še nekaj glede strukture:
* V svc_delay.s se v funkciji dl_arfd nahaja pogojni skok na labelo __dla_ovrflw,
ki pa se nahaja spodaj pod funkcijo dl_drfd! Taka struktura dela zmedo.
* Prav tako naj ima vsaka taka (notranja) labela jasen komentar kdaj se program
lahko nahaja v tem odseku kode.
* Lepo bi bilo da se spremenljivki DLYLIST/CDLYTCB premakne iz space.s v
svc_delay.s (oz. timers.s glede na zgornji komentar). Spremenljivke naj gredo
čisto
na konec v svojo .data sekcijo (glej npr. vm.s)
Vsebinski komentar na kodo:
* Koda odstrani globalni jiffies counter, ki šteje uptime sistema v številu
milisekund. Trenutno se le-ta uporablja zgolj za realizacijo timerjev, vendar
je
vrednost uporabna tudi drugje, tako da naj se obdrži.
* Alociran prostor za DLYLIST je 80 bajtov. Iz kje sledi ta številka in kako nanjo
vpliva večanje št. taskov ? Glede na to da lahko vsak task registrira zgolj
en
timer naenkrat naj se uporabi vrednost, izračunana glede na število taskov v
sistemu. V primeru dinamične alokacije taskov, bo potrebno dinamično
alocirati tudi
deskriptorje timerjev.
* DLYLIST zgleda kot polje in ne povezan seznam. To je težava, ker tako polje ni
preprosto dinamično spremenljivo. To se lepo vidi, ko je potrebno npr. dodati
nek
element v sredino - zamik vseh vrednosti je potraten! Poleg tega bo tako polje
predstavljalo problem, ko bo mogoča dinamično kreiranje taskov med delovanjem
sistema.
* Zakaj je potrebna spremenljivka CDLYTCB ? Ali ni mogoče trenutnega TCBja
razbrati neposredno iz seznama registriranih timerjev ?
Zaenkrat to.
Original comment by kos...@gmail.com
on 18 Dec 2008 at 12:15
* to glede strukture kode bomo popravili v kratkem, prav tako odstranili
nepotrebne
datoteke, ki niso potrebne za prevajanje kode.
* DLYLIST je velik 80 bajtov, ker je profesor na začetku zadal nalogo tako, da
naj bo
to tabela fiksne dolžine (za 10 procesov ker več jih ne bo za testiranje) ->
zato smo
se potem mi tako lotili nalogo, da smo DLYLIST ustvarili kot polje in dodali
samo
izhod v primeru overflow-a tabele, drugače bi seveda uporabili povezan seznam,
vendar
je povedal, da ni potrebno komplicirati.
CDLYTCB uporablja zato, ker so v tabeli shranjeni sami procesi, ki še čakajo
na delay
-> tisti, ki pa je trenutno v štetju ga tako ni več, to pa zato, ker lahko
vmes pride
zahteva za nov delay in bi zato tabelo DLYLIST premešalo skupaj s tem, ki je
trenutno
že v štetju -> zato se ga prej odstrani.
LpG
Original comment by gasper.r...@gmail.com
on 18 Dec 2008 at 12:48
1. Kar se tiče DLYLIST bo izvedba s poljem problem pri implementaciji
dinamičnih
taskov, prav tako pa vidim da je že problem pri odstranjevanju elementa - kako
namreč odstranite element iz polja ? Zamaknete vse elemente v levo (kar je
potratno) ? Če bi uporabili povezan seznam, bi bila rešitev veliko bolj
enostavna.
Skratka vaša rešitev ne omogoča enostavne uporabe kode v primeru, ko bomo
potrebovali dinamično resizable tabelo timer deskriptorjev (trenutna
implementacija
v trunku uporablja povezan seznam, kjer bi bilo preprosto dodati dinamično
alokacijo, ko bo le-ta na voljo).
2. Ko se izvede TC0 IRQ preverite kateri timer je naslednji v vrsti za
izvajanje
(to je vedno prvi). Kje bi lahko tukaj prišlo do zahteve za nov delay
(prekinitve
so tukaj onemogočene, ker smo v prekinitveni rutini) ?
Original comment by kos...@gmail.com
on 18 Dec 2008 at 1:34
Ni problema, to glede izvedbe DLYLIST-a preuredim čez praznike, najbrž ni
prof.
Mahkovič predvidel, da bo prišlo tako daleč s projektom.
Tisti čas, ko je en v štetju (ko čaka na TC0 IRQ) so omogočene prekinitve
in lahko
pride nova zahteva in se postavi v DLYLIST.
Ok, ko popravim to se slišimo
LpG
Original comment by gasper.r...@gmail.com
on 18 Dec 2008 at 6:03
no, pa da še jaz dodam svoje kratko irelevantno mnenje:
*asistent* dr. *Mahkovec* ni avtoriteta pri tem projektu,
neuradno odkar stoji /p/lbos-fri in podaljšan TODO (in poguba LBOS.pdf, sori),
uradno pa od Kosovega predavanja prejšnji teden.
Izključna avtoriteta po znanju, volji in ne po dolžnosti je, kot, vidim, si
že
sprejel, on, zato vprašaš in se posvetuješ z njim.
To je dobro in od njega se lahko jaz in ti, in vsi ostali pri vas, kdor dela, le
naučimo. In vsi ostali iz vseh drugih skupin. ;)
ja, in zdaj ta svc_delay...
a mi lahko prosim razložiš, kaj vaš svc_delay.s v osnovi dela drugače kot
bivši timers.s?
sicer, če popravljate/dopolnjujete/izboljšujete timers.s, lahko pišete kar
vanj
(popravite/dopolnite/izboljšate).
in če popravljate statično polje v dinamičen povezan seznam,
definirajte strukture (elemente seznama, primer oz. je že na pol definirano
http://code.google.com/p/lbos-fri/source/browse/branches/group8-perice/include/s
tructures.s#33
in naprej imaš še dva "REQUEST DESCRIPTOR") in za dodajanje elementov v seznam
uporabite dinamično alokacijo (sedaj funkcijo mm_alloc_page (in mm_free_page ob
brisanju), kmalu pa se bo ta nadomestila z kmalloc, ki bo bolj fin).
če sem prav razumel, gre za povezan seznam, urejen po 'number of jiffies'?
hvala za razumevanje :)
Original comment by jernej.kernc@gmail.com
on 18 Dec 2008 at 7:23
Ja, gre za povezan seznam, urejen po 'number of jiffies', kjer nek i-ti element
tabele v resnici predstavlja vsoto vseh pred njim v tabeli + samega sebe.
Bolj podrobno je napisano tu
->http://code.google.com/p/lbos-fri/wiki/planOfDelay
Na kratko...razlika je v tem, da je bivši timers.s uporabljal tak način za
štetje, da
je gledal na cur_jiffies (čas v ms od zagona sistema) in potem se po njem
orientiral
in brisal T_WAIT zastavice procesom. Ta pa deluje tako, da se postavijo v seznam
zahteve za delay tako, kot sem ga prej gor opisoval (in je na wiki-ju
predstavljen)
in potem postavi za štetje cifro, ki je v prvem elementu seznama...ko to
prešteje
briše zastavico T_WAIT prvega in vzame cifro drugega elementa seznama...itd.
To glede asistenta mi pa ni več jasno zdj kako...namreč takrat, ko smo se
nazadje tu
gor menil sem mu potem povedal, da je svc_delay na lbos-fri že narejen, sicer
malo
drugače...sam pa je odgovoril da on bo ocenjeval naš svc_delay, kot smo ga
dorekli ->
tko da zdj bi res rad zvedel kako je zdj s tem projektom? Da nbomo potem naša
skupina
ostala brez ocen zaradi nesporazuma z asistentom.
Meni seveda ni problem popravit statično polje v dinamičen povezan seznam (to
najbrž
nebi bil prevelik odmik od tistega kar pričakuje asistent od nas...in je
seveda tudi
dosti boljši), samo če bo pa delay implementiran čisto drugače kot smo se
na začetku
semestra z njim dogovorili (ko se je vsaka skupina hodila menit gor k njemu) je
pa
takrat reku, da ga nebo upošteval, kot da je naš...
Original comment by gasper.r...@gmail.com
on 18 Dec 2008 at 7:50
A lahko prosim brez nepotrebnega politiziranja tlele na bugtrackerju in da se
osredotočimo izključno na tehnično plat reviewja kode v group 3 branchu.
Hvala.
---
Torej kar se tiče zamenjave polja s povezanim seznamom je le-ta nujna za merge
v
trunk saj tam to rabimo zaradi prihajajočih dinamičnih taskov. Zanima me še
naslednja zadeva kar se tiče kode:
* Če prav vidim ste spremenili mersko enoto - 1 jiffie ni več ~ 1 ms, temveč ~
0.25 ms ?
* Vrednost zakasnitve posredujete neposredno timerju - to omeji maksimalno
zakasnitev na okoli 1 sekundo (register TC0_RC je zgolj 16 biten, maksimalna
vrednost 0xFFFF pa je zgolj ~ 1008 ms). To je nekam omejujoče ? Ravno zaradi
tega
trenutna implementacija v trunku uporablja ločen jiffies števec, ki je lahko
poljubno biten (trenutno je 32 biten, brez težav pa bi se lahko uporabljal
tudi 64
biten števec).
Če sem kaj spregledal me kar popravi :)
Original comment by kos...@gmail.com
on 18 Dec 2008 at 8:27
glej, jaz tvojega ne bom ocenjeval, zato me toliko ne jemlji za ziher.
vprašanje tudi, če bo tvoje ocenjeval mahkovec oz. če to dela, in sem se jaz
danes z
njim pogovarjal, potem bo groza :&
no, anyway, poskrbimo, da bo to kar boste oddali kar najboljše, če preseže
začetno
omejene zastavke, ne bo niti mahkovec nič jezen. se bomo tudi glede ocen na
koncu
skupaj zmenili :P
ampak še vedno pa mi ni jasen svc_delay. sori :>
kaj ti pravzaprav ni všeč pri izvedbi sedanjega timers.s, razen da ni urejen
dinamičen seznam? sedaj dela tako, da ko proces zahteva delay, se pogleda kok
je
trenutni jiffies (ki, btw, kaže uptime (---kako bomo naredili uro?)) in se mu
prišteje željeni delay in se vpiše aktiven timer. proces tako spi, dokler ga
timer_irq_handler ne zbudi, ko trenutni jiffies doseže shranjeni. kaj je tu
narobe?
ali delay delate izključno zato, ker ste se tako davnega zmenili s mahkovcem?
(to ni
dobro)
v tem primeru lahko imate. jaz ne bom commital v trunk. :)
P.S: sori, res mi ni jasno, gledam tudi (nekonsistenten?) primer na planOfDelay
in ne
razumem. kakšen je namen? kakšni potrebi zadošča?
to mi tudi ni jasno
"in potem postavi za štetje cifro, ki je v prvem elementu seznama...ko to
prešteje
briše zastavico T_WAIT prvega in vzame cifro drugega elementa seznama...itd."
in kaj pomeni to
"Thus we have achieved more counting delays by one timer."
?
sej timer je samo en?
še enkrat se opravičujem, da ne boš mislu, da se kej zajebavam :P
res mi ni jasno in res me zanima.
hvala
Original comment by jernej.kernc@gmail.com
on 18 Dec 2008 at 8:35
vse on topic :)
Original comment by jernej.kernc@gmail.com
on 18 Dec 2008 at 8:39
@kernc:
Ja ne, sej ni nič narobe s sedanjim timers.s v trunku in tud kot vidim se ta
delay
dela na tak način izključno samo zato, ker je tako določil asistent, kar vem
da ni
dobro...sam kej nej potem jest proti asistentu? Pa tudi ne vidim boljše
rešitve kot
to, ki je že v trunku...samo kaj naj potem pa mi naredimo?
Recimo da imaš tri procese, ki zahtevajo delay:
1.. 80ms
2.. 100ms
3.. 150ms
Koda jih postavi v strukturo tako:
|80|20|50
In nato da prešteti prvi element tabele (80ms). Ko tega prešteje je tako
preštetih
80ms vseh treh procesov (1.,2. in 3.)
Tabela postane sedaj:
20|50
Iz nje se vidi, da je ostalo še 20ms za 2. proces in 50ms za 3. proces. Tako
da sedaj
preštet spet prvi element tabele (20ms), ki predstavlja 20ms od 2. in 3.
procesa.
Sedaj ostane še:
50
Kar pomeni, da ostane za preštet še 50ms za 3. proces.
Skratka, ni navadna tabela urejena po velikosti, ker drugače bi bila naslednja:
80|100|150
In bi se najprej štelo 80ms za 1. proces, nato 100ms za drugi proces in na
konc še
150ms za tretji proces -> torej bilo bi zaporedno štetje in ne vzporedno kot
je pa v
našem primeru (s tem je mišljeno štetje delay-ev več procesom hkrati).
@kostko:
mersko enota je manjša zaradi potrate časa že v sami kodi -> vsekakor nujno
spremeniti v seznam.
Original comment by gasper.r...@gmail.com
on 18 Dec 2008 at 9:13
@gasper:
Ja povezan seznam bi moral izboljšati performanse, saj ne bo treba več
kopirat
stvari sem ter tja ob brisanju elementa. Kaj pa tisto glede maksimalne
zakasnitve ?
Tisto res velja ali sem kaj zgrešil ?
Original comment by kos...@gmail.com
on 18 Dec 2008 at 9:41
Ja, stvar sem preveril TC0_RC sprejme max zgolj samo 0xFFFF, torej bi blo treba
za
večje zakasnitve to realizirat nekako drugače...samo potem je že vprašanje,
kolk je
potem sploh še smiseln ta naš način realizacije?...ker če pogledam vse
skupaj, bo na
konc ta v trunk-u dosti enostavnejši...:-/
Original comment by gasper.r...@gmail.com
on 18 Dec 2008 at 10:43
rasper, hvala! končno se mi je posvetilo. :)
svc_delay v bistvu "računa" neke razlike med delayi, kar pa je, kot smo
ugotovili,
povsem nepotrebno, saj ima lahko vsak task svoj "realni" in se izloči natanko
predvideno.
in pri
80|100|150
se najprej 79 ms ne zgodi nič, nato se starta prvi in nato čez 20 ms drugi
... kot se
*že* dogaja sedaj.
torej, kar se mene tiče, lahko bivši timers.s za začetek popravite tako, da
bo
namesto v pool, shranjeval v *urejen seznam* ("navodila" v [c10]). tako bo
timer_irq_handler najhitreje vedel, ali je sploh delay in kateri.
potem pa bomo še kaj našli.
gut? :-)
Original comment by jernej.kernc@gmail.com
on 19 Dec 2008 at 7:49
Nekako se mi zdi, da bi lahko bila kombinacija obeh načinov (ta, ki je
trenutno v
trunk-u in ta naš način) bil kar hiter, če bi ohranil ta način shranjevanja
(kjer se
računa razlike med delay-i), samo da bi se shranjevalo v seznam in ne
tabelo...s
kombinacijo cur_jiffies načina, ki je trenutno v trunku...bom probal nekaj
poeksperimentirat, pa se bo pol na koncu vidlo, kako se obnese ta način oz.
kako je
hiter...sej to je itak glavno, da se dobi najboljšo rešitev, potem pa lahko
asistent
reče kar hoče :-P
LpG
Original comment by gasper.r...@gmail.com
on 19 Dec 2008 at 10:08
Točno tako, najboljša koda vedno zmaga :)
Original comment by kos...@gmail.com
on 19 Dec 2008 at 11:53
Dodana je nova koda za svc_delay...upošteval sem vse nasvete:)...sedaj se koda
nahaja
samo v timers.s
Kodo moram še v praksi stestirat (sedaj stestirana samo na papirju:) )...kot
sem
gledal z zdajšnjim timers.s v trunku, se razlikuje register_timer v tem, da ma
malo
manjša KO ter par ukazov manj...kera koda od teh dveh se pa še v praksi
hitreje
obnaša moram pa še stestirat.
LpG
Original comment by gasper.r...@gmail.com
on 7 Jan 2009 at 3:41
sedaj tudi stestirana.
Original comment by gasper.r...@gmail.com
on 8 Jan 2009 at 11:18
Original issue reported on code.google.com by
jernej.kernc@gmail.com
on 29 Nov 2008 at 7:41