From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Sat 06 Jul 2002 - 19:56:13 EEST
Selamlar..
On 06 Jul 2002 14:35:37 +0300
Murat Koc <murat.koc@frontsite.de> wrote:
>
>
> > Selamlar..
>
> Selam,
>
> > Genel olarak bakildiginda SWAP'in amaci bu.Biraz daha genellestirirsek,
> >SWAP, Virtual Machine sisteminde, process yukunun artmasi ile VM
> >isteklerinin fiziksel RAM ile karsilanamaz duruma dusmesinde kurtarici
> >olarak kullanilir. Bir process'in dinamik olarak kullandigi RAM (DATA
> >segment) gibi, process'in kendiside (TEXT segment) SWAP'a konabilir. Bu
> >dogru tarif degil tam olarak ama, sunu anlamak icin faydali olur. Bazi
>
> Bunu yazmistim. ne tur page lerin konulabilecegini. TEXT segment swap e
> konmaz. Cunku read-only oldugu icin modify edilemez dolayisi ile o page
> free yapilmadan swapped=out yapilmasinin bir anlami yoktur. Cunku
> gerektiginde zaten orjinal dosyadan demand-paging yapilabilir.
Dahasi, copy-on-write edilebilir..
> >isletim sistemleri uzun sure Sleep durumunda kalan uygulamalari
> >otomatikman SWAP'a koyabilir. SWAP'ten bir process'in tekrar
> >yuklenmesi, process'in yeniden baslatilmasindan kat kat hizlidir. Bu
> >nedenle bilhassa yuksek yuke gore dizayn edilmis sistemlerde,
> >process'ler yuke binmeden baslatilir, bir sure sonra OS bunlari SWAP'e
> >koyar. Ihtiyac oldugunda bunlari yuklemek daha kolay olur. Linux bu
> >konuda biraz zayiftir. Fakat Solaris ve AIX bu isi cok iyi becerirler.
> >Fakat Linux copy-and-execute yapabilir, yani calisan bir sureci
> >hafizadan kopyalayarak yeni bir surec olusturabilir. Boylece bu sorun
> >daha etkili olarak cozulmus olur.
>
> himm ben anlamadim bunu? bahsettigin bu durumu bilmiyorum yani uzun sure
> sleep modda kalan process ler swap e atilir sonra oradan geri yuklenir
> filan. Bu bana pek mantikli gelmiyor simdi process table dan swap e
Bu biraz nostaljik bir yaklasimdi. Eski SCO'larda filan faydali oluyordu. Guncel UNIX'ler icin gereksiz bir durum.
> attiginizda bu durumda zaten cikarmis oluyorsunuz geri yuklemek icin ise
> oncelikle diskten okumaniz gerekir o page leri ki tekrardan ona PID,
> session leadership bilgilerinin degistirilmesi gerekir. Bu durumda page
Yok, process'ler zaten oyle davranabileceklerine gore .TEXT .DATA sahibi olurlardi. Process calisir, beklemeye baslar. Bir sure sonra kernel onu SWAP'a yollar, bos fiziksel bellek olsa bile. Calismasi gerekince sadece, SWAP-IN islevi yapilir. Elbette bunlar onumuzdeki Linux icin yaptigim bir tarif degil. Guncel olarak saniyorum True64 ve Solaris kullaniyor. Yaniliyor olabilirim. O sistemlerle ugrasmayali yillar oluyor, kiyida kosede okuduklarimdan aklimin bir kosesinde kalan bir durum, True64 ve Solaris. Fakat bu mekanizmayi, eskiden bol bol kullanirdik. En son Kutahya Belediyesinde, ACER-ALTOS'larin bellegi yetersizdi, programdan programa gecerken SIGSTOP ile uyutmalarini onerip bir hayli performans saglamistik, hatirladigim kadariyla. 8 MB RAM ile, 386DX-33 25 dump terminalle calisiyordu. Bizim gibi dinazor olunca, boyle Kambriyenden kalma cozumler pek unutulmuyor..
> in orjinal dosyadan okunmasi ile swapden okunmasi arasinda pek bir fark
> kalmiyor. ki bence bahsettigin bu islem ise ancak karmasaya yol acar.
> Ayrica linux un bunda zayif olmasini anlamadim ve buna karsilik da linux
> copy-and-execute yapabilir i anlamadim. cop-and-execute ile sanirim
> fork-exec ikilisini soylemek istedin ki bu zaten yeni bir process
> olusturmak icin gerekli olan prosedurdur. Solaris ve AIX de fork-exec
> kullanir? Dolayisi ile bu bahsettigin seyi ben hic anlamadim nasil bir
> fayda sagliyor? linux nasil zayif? standart process olusturma islemi ile
> bunlari ne alakasi var?
Bu birazcik, genel SWAP process'i ile ilgili. Linux Spesifik degil. Ornegin Solaris hatirladigim kadari ile uzun sure sleep durumunda kalan process'leri SWAP'a koyabilir. RAM bombos olsa bile bunu yapabiliyor. Olusacak bir ani RAM gereksiniminde SWAP ile zaman kaybetmek istemiyor saniyorum. Devrim SERAL, senlikte, SWAP yuksek duruyor deyince, boyle bir aciklama yapmisti, yanlis hatirlamiyorsam, oradaki SPARC icin.
Copy-and-execute degildi tam adi. Diyelim ki, A kullanicisinin calistirmis oldugu VI, b kullanicisi tarafindan calistirilmak istenirse, A'nin acmis oldugu VI segmenti, B icin kopyalanarak kullanilir. Elbette durum sadece TEXT segmentlerini kapsiyor. Boylece diskten tekrar programi yuklemek gerekmez. Fakat, konqueror gibi acildiginda bir suru dosya erisimi yapan programlar bundan cok etkili olarak faydalanamiyor dogal olarak.. Devamini okuyalim, biraz daha netlesecek..
> > SWAP isinde en can alici nokta, Murat'in belirttigi swap-out kismidir.
> > 386 Mimarisinde bellek Virtual86 modunda kullanilir. Bu modda, bellek
> >4K sayfalar halinde tutulur ve swap-out kolaylasir (nispeten). MMU
> >sagolsun.. Ama, bir process'in user level thread modeli, kernel
> >tarafindan bilinmeyebilir. Eger, pthread gibi bir user-level thread
> >sistemi kullaniyorsaniz, thread onceliklerinizi belirleyemeden onlarin
> >SWAP out'a fazla dusmesi mumkun olur, bu da performans kaybina yol
> >acar. Nasil ?
> >
> > Bir user-space thread, kernel tarafindan process'in bir parcasi gibi gorunur.
> > Kernel threadlari ise kernel tarafindan bilinir ve daha iyi SWAP ve
> >process yonetimi saglar. Demekki, pthread "POSIX thread" kullanmak swap
> >mevcut olan bir sistemde cok verimli olmaz :(( Ama penguenciler
> >uyaniktir. Bakin ne yapmislar: POSIX threadlarini implement eden
> >pthread library'sin libc'ye gommusler ve clone() ile bunlarin bir
> >kernel-thread olarak calismasini saglamislar. Ama user space
> >sync-thread (fiber) destegide yokolmus otomatikman. Gerci buyuk bir
> >kayip degil.
>
> bu thread konusunu sanirim onceden de (bayaa once) konusmustuk. Yalniz
> bunlara kernel-thread demeyelim kernel-level-thread diyelim daha duzgun
> olacaktir sanirim. Serdar ben bu ikisini birbirine sokulmus sekilde
> goruyorum burada. kernel-thread ile kernel-level-thread farkli
> seylerdir. pthread in kernel-thread ile alakasi yoktur. kernel-thread
> denilen sey kernel_thread() ile olusturulur ve kswapd buna iyi bir
> ornektir. PID leri 2,3,4 ... gibi kucuk numaralar olurlar ve priority
> olarak en yuksek seviyede calisirlar (RING 0) ve kesinlikle USER memory
> ile alakalari yoktur direk KERNEL memory i share ederler. Bir MT
> application inin bu LWP lerin gucunu kullandigi dogrudur ama her
> application MT olarak yazilmamis olabilir ayrica LWP leri solaris filan
> kernel-thread olarak process ederler ama biz Linux bazli konusuyoruz ve
> Linux burada standart disi olarak bu isi clone() ile yapar ki bu bir
> kernel_thread degildir. kernel_thread() da sonradan clone() u cagirir
> orasi ayri.
Dogru, kernel-level demek gerekiyor. Zate en bastada, ne alakaysa, nerden estiyse, "Linux Virtual86 modunda calisir" yazmisiz. Fakat, LightWeight Processlerde Linux ile de kullanilabiliyor. Dogru, kernel-thread ile LWP'nin alakasi da yok.
Buna bende tam olarak ne diyecegimi bilemiyorum. POSIX thread'leri user-level threadlerdir. Bu nedenle kernel tarafindan senkronize edilmez. Scheduler bunlar icin process'e ayirdigi zamani kullanir. Process icersinde threadler handle edilir. Bu birbirini etkileyen threadlerin senkronize calisabilmesini saglar. Bilhassa I/O islevlerinin verimi artar. Iste boyle user-level threadleri bir kernel-level thread handler'e baglarsiniz. Bilinen Many-to-Many yontemiyle. Bunlara fiber denir ve NT ile W2K bunu son derece iyi kullanir. MS-SQL ve ISS'in yuksek performans gostermesi bu sebepledir. IKide birde cokup durmalarida ayni sebepledir. Thread'ler bizim setpriority gibi bir kernel uzantisi kullanmadan, pre-emptive yerine bir tur cooperative multitasking yaparlar. Boylece thread'larin surekliligi daha iyi olur.
Fakat Linux'taki pthread'ler, kernelden clone ile olusturulur. Hepsinden kernelin haberi vardir ve scheduling kernel tarafindan yapilir. Gene soylediklerimiz biraz karisik oluyor. Linux'taki POSIX implementasyonu, POSIX'teki tarifin aksine, threadlerin kernel tarafindan schedule edilmesini saglar. Boylece kernel'in her thread icin yeterli zaman ayirmasi saglanir. Bir process icinde olusturulmus her thread kernelin scheduling tablosunda yer alir.
BU neden boyledir. Linux'un bir copy-on-write mekanizmasi vardir. /arch/i386/mm/fault.c icinde bir kac fonksiyon vardi saniyorum bununla alakali. Eger, A vi'yi baslattiktan sonra B vi'yi baslatirsa, ayni bellek adresleri virtual olarak esitlenip, gereksiz RAM kullanimi onlenir. Yani hafizadaki tek vi kodu, her kullanici icin ayni kod olarak calistirilir. Diyelim ki, A bu ortak kodda bir yeri degistirdi, A'nin degistirmek istedigi sayfa, yeni bir fiziksel sayfaya tasinir, boylece bellekten maksimum fayda saglanir. Linux'un daha dusuk bellekle daha iyi is cikarabilmesinin esprisi biraz buradadir. Demekki kod icin kullanilacak SWAP hesabi biraz karisik. Cunku, kodlarin ne zaman process basina yeni sayfalar acacagini tespit etmek biraz zor. SWAP gibi, maksimum RAM miktarini hesaplamakta bir hayli zorlasiyor. Diger yandan thread'lerinde etkinligi artiyor. Bilhassa SMP Sistemlerinde. Squid, tek bir process olarak yuzlerce thread kullanip, Apache'nin connection per process modeline gore daha efektif olabiliyor. Cun
ku thradler, processler gibi pid, signal handling vs. mekanizmalari gerektirmiyor. Ama bir thread sigsegv yerse, tum process cokuyor haliyle.. Bu da dikeni..
> > Thread ile SWAP arasindaki baglanti, thread'in scheduling que'de sirasi
> >gelince isleniyor olmasindan kaynaklanir. Eger sirasi gelen thread
> >swap'ta ise veya bos bellek yoksa, SWAP islevi baslar. Bu da kernelin
> >tek bir thread (one-to-many) olarak gordugu bir process'i SWAP'a
> >gereksiz yere atmasiyla sonuclanabilir.
> >
>
> iyi de ben thread kullanmiyorsam. Butun programlar veya process ler
> thread kullanmak zorunda mi? ben kodumu yazarken sadece fork-exec
> yapiyorum belki ne clone() ne de pthread_create() kullanmiyorum. Bu
> durumda bunun benim icin hicbir anlami olmaz ki? Calistirilan her
> process illa ki MT sekilde calistiriliyor degil ki?
Dogru, ama, Apache, Sendmail, BIND, squid vs. boyle yapmiyor. Bunlarin .DATA ve .TEXT ihtiyaclarini belirlemek de cok kolay olmuyor haliyle. Diger yandan Apache ve Sendmail'in process yaratmadaki istahi, squid'in process yaratmam illa inadiyla cakismiyor. Bu nedenle gerekli bellek miktarini hesaplamakta kolay olmuyor.
Yani, genelgecer bir SWAP'i su kadar yapin cozumu yok maalesef..
> > Peki bunlari neden yaziyoruz ? SWAP yonetimi, boy pos tespiti vs.
> >sistemin kullandigi thread modeliyle son derece alakalidir. Bu tur bir
> >thread yonetimi, SWAP yonetiminide kolaylastirir. Demekki, SWAP'a
> >ihtiyaciniz varsa, uygulamalarin thread modelini cok fazla dusunmeden
> >bir SWAP modeli cikarabilirsiniz.
>
> butun alakayi buna baglayamayiz. Eger boyle birsey yaparsak benim
> swapping konusunda yazdiklarimin hicbirinin anlami olmaz.
Bir diger thread mailseminer'ind bu konuya iyice bir dalalim. Bu thread mevzusunun SWAP ile alakasi soyle. W2K gibi sistemler Fiber tabanli user-level threadler kullanir. Bunlarin ne zaman SWAP'a gidecegi kritiktir. Olmadik bir zamanda, SWAP-OUT ederseniz, o cok hizli denen MS-SQL birden surunmeye baslar. Bu nedenle W2K gibi sistemler icin SWAP hesabi zor bir durumdur. Bilhassa SWAP-OUT hesabi. Ayni nedenle W2K, NT gibi sistemler bir turlu Bellege doymazlar. Fakat Linux'ta kernel, fiber filan bilmez, kullanmaz. Bilhassa processler icin en optimize RAM destegini sunar. Bu nedenle SWAP hesabi cok daha yuvarlak yaklasimlarla yapilabilir. 10.000 simultane web baglantisi, 10.000 httpd demektir. 1 http 4 MB isterken, 10000 tanesi icin bu deger http basina 100K'ya dusebilir. copy-on-write mekanizmasinin sagladigi benim tabirimle "copy-and-execute" yani, gereken kismi kopyala ve calistir duzenegi sagolsun. Disk erisimi nerdeyse sifir. Eski gunlerdeki gibi, process'i bastan bir kere baslatayim, SWAP'e gitsin, gerekti
ginde kolayca yeniden yuklenir derdide yok..
Linux'un en buyuk performansi vermiyor olsa bile her zaman yeterli performansi verebilirken stabil olabilmesi bu mekanizmaya dayanir. Ustelik kafa kirdiran que hesaplari yapmak bile gerekmez cogunlukla. Bir onceki maildeki gibi yuvarlak yaklasimlar dahi %99 sistemde mantikli is yapabilir. Gerci o degerler benim gozlemlerim sonucu elde edilmis seyler. Her tur tartismaya acik..
SWAP mekanizmasi ile Thread mekanizmasi birbirleriyle baglantili degil gobekten.. Fakat, SWAP-OUT'a tabi tutulacak sayfalarin seciminde ve SWAP'in asil hedefi olan "Not Enough Memory" derdini ortadan kaldirmak konusunda bu thread konusu etkili. Kernelin ne zaman neyi swap edecegini daha iyi tespit edilmesini sagliyor, bellegin daha iyi kullanilmasini sagliyor boylece SWAP ihtiyacini azaltiyor. Boylece SWAP-OUT, x86 mimarisi icin daha dogru deyim olan "Page Fault Handling Mechanism" daha isabetli gerceklestirilebiliyor. Page Fault Handling mechanism diye bir tarif yok. Ama CPU'nun page fault exceptionlarini isleyen kodun bir parcasida SWAP mekanizmasi. Bir kernelin kendisinin 0 sistem kaynagi harcamasi istenir. Yani 0 RAM, 0 CPU time.. Neden ? isi yapan kernel degil processlerdirde ondan. Elbette bu imkansiz. Ama iste scheduling, task switching, process start, SWAP efficiency vs. icin harcanan sistem kaynagini 0'a olabildigince yaklastirmaya ugrasirsiniz. Ve thread modelinde filan Linux Developerleri en optim
um yolu boyle gormusler. Buradaki yumusak karin SWAP. Digerleri tamamen asilmis. SWAP ihtiyacini azaltmak icin thread mekanizmasini duzenlemisler iyice. Her sey kernelin denetimine kalmis. Boylece SWAP hesabida kolaylasmis bir nebze..
Kisacasi, onceki mailde yukarida yazilanlar, genel thread yontemlerinin kabaca bir analizi. Linux spesifik thread yontemleri icin KernelAnalysis-HOWTO'yu biraz eseleyebilir, Linux SWAP mekanizmasi icin Murat KOC'u izlemeye devam edebilirsiniz. Ben oyle yapiyorum su anda ve Bolum 4'u bekliyorum istahla.. Bizde arada boyle saplamalar yapar, KOC'un tum beynini hortumlariz bahaneyle. %10'unu kapsak, gider bir yeni kernel yazariz herhalde..
Yeni yorumlarini bekliyorum. Bu tarafa gelde, serinde bir karpuz keselim, soyle kizilirmaga karsi.. Inan yorgunluk atmak icin birebir oluyor..
Bu arada, bu gunlerde dilim cok surcuyor. Soyle ki tereddutlu oldugunuz seyleri duzeltmekte veya sormakta tereddutsuz olursaniz sevinirim.
Saygi ve sevgiler..
-----------------------------------------------------------------------
Liste üyeliğiniz ile ilgili her türlü işlem için
http://liste.linux.org.tr adresindeki web arayüzünü kullanabilirsiniz.
Listeden çıkmak için: 'linux-request@linux.org.tr' adresine,
"Konu" kısmında "unsubscribe" yazan bir e-posta gönderiniz.
-----------------------------------------------------------------------