Re: lug-bg: Mem usage Linux&Windows

[vtzankov@xxxxxxxxxxx (Valentin Tzankov)]

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
============================================================================