Autor: Jan Stožek (jasio_at_polbox.pl)
Data: Mon 19 Jan 1998 - 16:20:19 MET
On Mon, 19 Jan 1998 11:31:33 +0100, Leszek Gerwatowski wrote:
:>On Thu, 15 Jan 1998, Grzegorz Wnęk wrote:
:>
:>> > >Komputer wiesza się w momencie pojawienia się logo, więc podejrzewam, że
:>> > >problem tkwi na początku config.sys.
:>> > >Na początku mam tylko ifs do HPFS i CDROM - dalej już chyba nie
:>> > >dochodzi, bo wyREMowanie ifs do cdrom nic nie daje - może się wiesza
:>> > >przy ładowaniu HPFS? Hmm.
:>> >
:>> > nie. config.sys nie jest interpretowany po kolei. os/2 raz skacze
:>> > do jego srodka, na koniec, a poczatek moze obrobic dopiero na samym koncu :)
:>>
:>> To czemu sluzy taki smieszny programik z pakietu cfginfo do
:>> porzadkowania config.sys - zeby tylko ladniej wygladal?
:>>
:>
:>Nie. Sluzy on temu zeby sie system szybciej ladowal bo jak jest config.sys
:>uporzadkowany to system juz nie mysli gdzie skoczyc po kazdej instrukcji
:>tylko wykonuje po kolei bo on robi np. najpierw wszystkie basedev=,
A skąd on wie, że to już wszystkie? :)
:>potem wszystkie device= (tak na zdrowy rozum to musi byc wstydliwie prosty
:>algorytm okreslania co on ma ladowac skoro takie posortowanie config-a az
:>przyspiesza ladowanie - pewnie sobie ustala ze ma np. ladowac teraz
:>basedev=, zczytuje linie i patrzy "basedev? to laduje, a jak nie to ide
:>dalej.").
Gdyby się dało CONFIG wczytać w całości do pamięci i posortować w rozumie (albo i nie
sortować, tylko trzymać i przeszukiwać...), to program sortujący _niczego_ by nie przyspieszył.
Skoro loader jest przystosowany do losowej kolejności wierszy, to i tak musi przeszukać plik do
końca, bo skąd ma wiedzieć, że jeden CONFIG jest posortowany, a drugi nie? Czyli znowu -
posortowanie nie powinno znacząco przyspieszyć startu systemu. Być może całe przyspieszenie
jest efektem braku cache'a w początkowym etapie startu systemu i zmniejszenia ilości seeków
jakie musi wykonać dysk. Hmm... policzmy... Mój config ma jakieś 6,5 KB, czyli w najgorszym
wypadku 13 bloków... czy 13 * 8 (ifs-y są ładowane w "ósmej" kolejności, po basedev, libpath,
setach, codepage, country, devinfo i części device (OS/2 drivers)) * 2 (do configa i spowrotem) =
208 dodatkowych seeków... przy realnym średnim czasie dostępu 33 ms daje to prawie 7
sekund... ciekawe. Muszę to zmierzyć. :)
Pozdrawiam serdecznie,
(js).
mailto:jasio_at_polbox.pl
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:16:01 MET DST