The State of Linux IO Scheduling For the Desktop?

Mar tobbszor le akartam irni $related topikokban, mennyire furcsanak talalom, hogy csak a mainline kernelbe soha be nem kerulo patchekkel lehet desktop celra erdemben hasznalni, de a reality distorsion field mindig elrettentett. Orulok, hogy mashol azert elojott a tema.

( uid_4263 v | 2010. 10. 24., v – 12:18 )

"The one thing that constantly drives me mad is its IO scheduling. When I'm copying a large amount of data in the background, everything else slows down to a crawl while the CPU utilization stays at 1-2%. The process which does the actual copying is highly prioritized in terms of I/O. This is completely unacceptable for a desktop OS."

Nekem a Win7 pontosan ugyanígy viselkedik (SATA2-es vinyók között pl.)

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

Mert ez a hardware limitációja. Még nem jött el a desktop hardware éve :-D Még nem láttam olyan rendszert, amelyik az elvárható sebességgel másolt volna nagy adatmennyiséget a háttérben, miközben a desktop meg nem lassult be - illetve de, de az meg nem kifejezetten desktop volt.

Hát szerintem megoldható kéne, hogy legyen. Az, hogy az IO-t nem használó programok is lelassulnak (akkor is, ha van elég memória), az nem a hardver limitációja. Amikor a programoknak rövid IO műveletekre van szüksége, azt is meg lehetne oldani cache-eléssel, és azzal, hogy a nagy adatmennyiség másolását szüneteltetjük, amikor gyakran van szükség más programoknak lemezműveletekre (ez nem kéne, hogy gyakori legyen).

Nem totál használhatatlan, hanem amint olyan műveletet végez az épp használt program, ami I/O-val jár, akkor várakozni kénytelen a háttérben futó másolás miatt. Kisebb-nagyobb különbségek vannak, de mondom, nem láttam még olyan hétköznapi vason futó rendszert, ahol az jelentős különbség lett volna. Persze jó I/O ütemező biztosan meg tudná oldani, hogy megfelelően osztja el a prioritást, de ez attól még hardware limitáció marad, egy eszköz egyszerre csak limitált írást/olvasást tud prezentálni, és ha azt épp lekötöm egy nagyobb adatmozgatással, akkor várnom kell. Persze ha az ütemező úgy döntene, hogy minden nagyobb prioritást kap az épp használt programok közül, mint a másolás, akkor nyilván arról menne a panasz, hogy lassú a másolás... Lehet csiszolni sok/nagy cache-s diskekkel, RAID-del, megnövelt memória cache-el, de "azellen nemvéd", ha kellően nagy adatmennyiséget indítok útjára.

Ha nem próbáltam volna desktopnak a freebsd-t, akkor nyilván most zavarban lennék. De mivel próbáltam, nem tartom megalapozatlannak azt az állításomat, hogy nincs egetrengető különbség. Tovább megyek, linux és linux között ugyanazon a gépen nagyobb különbségek tudnak adódni, mint egy jól eltalált linux és freebsd között. És még mielőtt elmennénk a benchmarkok irányába, kiemelném, hogy ez desktopon, egyszerű PC-n, hétköznapi, átlagos vason, nem RAID disken, spec. vezérlőn, stb. tapasztalt eredmény. Ja, egy dolog, ami esetleg még ebbe beleszólhat: évek óta xfs-t használok fájlrendszernek, amikor anno váltottam, az egyik ok épp az volt mellette, hogy nem halasztotta le úgy a gépet, ha nagy mennyiségű adatot kezdtem el mozgatni.

( balintdavid | 2010. 10. 24., v – 13:00 )

subscribe

Régebbi debianos gépemen ez eléggé idegesített.
Valamennyit segített rajta, hogy amíg nagy fájlokkal dolgoztam (szerencsére csak ritkán kellett), a swapot totál kikapcsoltam (mert idióta módon telepakolta, pedig volt benne ram dögivel), és átnyomtam deadline schedulerre.
Elég ótvar workaround, gondolom ennél van jobb megoldás is.
-------------------------
$ killall npviewer.bin

( gd | 2010. 10. 24., v – 14:06 )

openSUSE-n is szar ilyen szempontból, még az IO-t nem használó műveleteket is le képes lassítani. Szerintem a CPU schedulingon is lenne még mit javítani. Más oprendszereken nem tudom, mi a helyzet.

( VaZso v | 2010. 10. 24., v – 18:53 )

Néhány napja keresgéltem kicsit bizonyos dátumok közötti fileokat Mandriván, KDE4 alatt a dolphin keresőjével.
Szó szerint használhatatlanná vált közben a rendszer. Ablakváltás akár egy perc, böngészni képtelenség, olykor egérkurzor is mozdulatlan volt.

Egyébként nem szoktam intenzív fileműveleteket végezni, más körülmények között nem tűnt fel a dolog.
Ez viszont nagyon durva volt, ráadásul két gépen is tapasztaltam. Közülük az egyik teljesen alap kernellel van.

( goodbyte v | 2010. 10. 24., v – 21:29 )

Subsc.

Holnap én is kipróbálom. Netbook, laptop és egy desktop rendszer (mindhármon Mandirva 2010.1 fut). Ha valahogy belövöm az X-et AIX alatt akkor az RS/6000-esen is kipróbálom !

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( nanto | 2010. 10. 25., h – 13:41 )

koszonom a topikot, Windowsokban es Linuxokban alairom, hogy ez nagyon siralmasan van megoldva, de idonkent maga a CPU scheduling is. Masolas kozben 2010-ben akadozik az egyebkent 1% CPU-t hasznalo film es renice segit valamennyit rajta, az nem eppen jo, teljesen egyetertek. Windows 7-en még talan turheto, de ott is van ezzel baj boven, de hozzatennem, hogy nem nagyon probaltam az erre szant Linuxos megoldasokat (pl. Con Kolivas patch). Amirol nem tudok nyilatkozni az a BSD-k es az OS X, de kivancsi lennek, abban ez jol van-e megoldva

( PcZolee v | 2010. 10. 26., k – 17:02 )

Na, erre ránézek majd én is, bár állítólag a 2.6.36-al vmit javult a dolog (vki próbálta már?). Minden esetre, néha tényleg elég idegesítő tud lenni.

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds