Linux-a systo swap-wa idle processi no e s mnogo malki segmenti, pone v kernel-a sa zalojeni 8,16,32K blokove,
i taka Linux ne moje da izpolzva spored men dobre bandwidth na HDD( 35-45 MB/sec),
az znam che ima mnogo prichini tova da e taka i ne smjatam che e nedostatyk,
no ot druga strana MS javno swapvat-a na ogromni segmeni,
mnogo mi e interesno kak go pravjat spored men te vinagi sa imali problemi s fragmentatziata,
a swap-a im ochevidno raboti mnogo dobre.


George Danchev wrote:

On 07 02 2003 02:56, Valentin Tzankov wrote:

George Danchev wrote:


Tova koeto se opitvah da napravja e da serializiram
GTK Widget-i i edni ogromni dyrvovidni structuri pod C,
no ne e lesna rabota, mnogo e bavno, a i ste e po-evtino
za clienta da si kupi 2048Mb RAM.

eh ne e mnogo qsno kakvo iskash da napravish, no s GTK, nezavisimo koq versiq mogat da se pravqt ubijstveno byrzi i ubijstveno bavni programi, zavisi koj i za kakvo gi pishe. I to ne e samo do ... kolko byrzo ti izka4a syotvetniq dzham, a i kakvo vyrshi code-a prez tova vreme, kolko pamet (i kolko 4esto) zaema i osvobozhdava samoto prilozhenie ostavq li mem leaks i t.n..... mislq ve4e si ubeden 4e ot samoto prilozhenie ne mozhesh da komandvash kernel-a dali da mqta na swap ili ne, koito i da sa mempages ;-) ... Zavisi i ot kolko thread-a ili fork-a se systoi tvoita programa, napr. edin thread za audio, edin za video i t.n , ste se vidish v zor dokato im sinhronizirash zada4ite kakto iskash (tuka se iska i dobyr context switching ot strana na kernela za da izglezda vsi4ko gladko).... ili vsi4ko e v edin thread kato pri MPlayer-a naprimer ... Maj e naj-dobre da se govori s code, stoto ina4e si prikazvame naizust...

Hubava si e Java che si ima serializatzia ama zasto Swing-a e tolkova
baven.
neznam kakvo da kazha tuka.

Neznam dali MS gubjat na byrz disk e nezabelijimo
osven tova kogato prilojenie e napyno nevidimo
systo otiva v swap-a pri malko pamet i "ALT"+"TAB",
prevkljuchvaneto se zabavja samo sys dve tri sec.

heh. mislq 4e gledash na nestata povyrhnostno ... Zavisi ot samoto prilozhenie kolko pamet zaema v daden moment i kolko osvobozhdava v daden moment (kato mempages)... Mozhe prilozhenieto da e "kazalo" *ptr = (void *)calloc(5000000, sizeof(int)) i sled tova kato napravish nesto si da pravi free(ptr);... Tova 4e se osvobozhdava RAM hi4 ne zna4i 4e tezi pages otivat v swap-a... Prilozheniqta iskat ili osvobozhdavat pamet ot sistemata, a tq reshava dali da swap-va ili ne i koga (v koj moment) i kak (s kakva intenzivnost)... t.e. da im razhvyrli i sybira tehnite data po stranicite iz rama i swap-a (ako go ima)... Tozi diapazon ot mempages go preravq samiq kernel... prilozheniqta (mogat da sa ot mngo procesi - fork, threads) "neznaqt" to4no kyde sa im stranicite... Ako opitat da pishat po 4uzhdi memranges, to rabota na kernel-a e da gi ivedomi 4e tova e neprili4no povedenie. Ako se opitat za iskat prekaleno mnogo mempages i sa nastoqtelni (pove4e otkolkoto ima nali4ni v sistemata) to rabota na kernel-a e da gi uvedomi 4e sa tova e neprili4no povedenie.

Pri Linux ako startirash process kojto da izjade pammeta,
ste minat minuti za da privkljuchish s "ALT"+"TAB" .

heh, a pri emes kak e ? pri kojto i da e kak e v takyv slu4aj... Obektivno sravnenie i test trudno ste izsimulirash .... zavisi kolko pamet e zaeta i ot kyde kernel-a ste trqbva da "vadi" prilozhenieto koeto si poiskal (t.e. da mu sybira negovite mempages, i to ne vinagi vsi4ki)... Za tova Linux keeps in mem cache dokato ima vyzmozhnost... No za da si pozvolish tozi luks s cache-vaneto trqbva kernel-a byrzo da mozhe da alokira, mesti i osvobozhdava pamet kogato tova se nalaga... katoprez tova vreme prodylzhava da context-switch-va drugite procesi za da izglezhda vsi4ko gladko ...

Mislja che MS mnogo dobre si sinchronizirat
kernel-a i gui-to,
az mislq 4e ot psihologi4eska gledna to4ka kogato zabravish vsi4ko ostanalo i "pokazhesh" na potrebitelq dzham mnogo byrzo toj si misli 4e programata mu raboti byrzo ;-) ... Tova e mngo dale4 ot postiganeto na golqma obsta proizvoditelnost ... nisto 4udno nqkoj 4asti ot grafi4niq interface pri emes da rabotqt v kernel space (vypreki 4e ot NT 4 maj sa na microkernel i ne se znae koq 4ast kyde mozhe da e implementirana da raboti t.e. na koj cpu ring, ako znaesh kakvo e tova)


vjarno e che kato ti zabie XServer-a linux-a
si prodyljava da raboti
XFree86 e edno ot malkoto priozheniq na koeto po4ti vsi4ki Unix-es mogat da mu davat da pishe direktno v /dev/mem ... Tova e za byrzina, no akoXFree86 napravi losh zapis, togava sle posledva hard lockup, stoto mozhe da se omazhe i mqstoto v pametta kydeto kernela si store-va svoite kernel-code i kernel-data ... tova ne sym mnogo siguren dali e bash taka, imam symneniq razni ;-)

dokato tova ne e s NT i 2000
ne znam kak pri XP.

zavisi ot NT nagore sa microkernel, ako bad gui code zabie, to ako e v samiq microkernel, sledva hard lockup, ako ne e to systemata naj-veroqtno ste prodylzhi rabota makar i s problemi ... (think GnuMach and Hurd servers...)

Vyobste rabotata e dosta po-slozhna i samo s nabludeniq ne se vadqt zaklu4eniq ... pri Unix-es graf. server e v user-space za tova mozhe da ti se struva ponqkoga bavno, ako taka byde implementirano i pri emes neznam kolko bavno ste da e ... Az li4no ne sym privyrzhenik xfree86 ili 4asti ot nego da bydat nabutvani v koito i da e unix kernel ... (monolythic ili micro ...)


============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================

Reply via email to