- Katılım
- 7 Aralık 2019
- Mesajlar
- 10.107
- Makaleler
- 1
- Çözümler
- 70
Dogru oldugunu kanitla ozur dileyeyim.
Dogru oldugunu kanitla ozur dileyeyim.Diyecek bir şey yok. Üzgünüm, doğruları söyleyince dokuz köyden kovuyorlar.
Bu konu içerisinde aynı sorular tekrar tekrar anlaşılır şekilde cevaplandı. Soracağınız soruların hepsinin cevapları var.Dogru oldugunu kanitla ozur dileyeyim.
Bu konu içerisinde aynı sorular tekrar tekrar anlaşılır şekilde cevaplandı. Soracağınız soruların hepsinin cevapları var.
Tabeladan sadeceFakat hala topluluk projesi halinde.
Tabeladan sadece.
Sadece gecikmeyi belirleyen etken bu değil? Birçok dağıtımda açık geliyor. Bunun haricinde işlem yöneticisi, I/O yöneticisi gibi faktörler de var. Gerçekten latency aransaydı CONFIG_HZ_1000 veya 500 gibi daha yüksek süreler seçilebilirdi. Daha çok throughput'a yönelik.
Bu da senin sorunun cevabi. Ne anlama geldigini bilmedigini bildigim icin sana kisa yoldan gostereyim. Cikan kernel configi icinde preempt sozcugunu aratiyorsun cevap karsina cikiyor.
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
Eksik olmasin kernelin server icin konfigure edilip edilmedigini CONFIG_HZ ayarindan da anlayabilirsin. Server icin konfigure edilmisse 100HZ olur.
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
Voluntary kernel preemption yani Desktop kerneli kullaniyor troughput amacli server kerneli degil. Buna da bir cevap verirsen senin yerine ben psikiyatra gidicem.
Bu kernelin hangi amacla kullanilacagini belirliyor yani sorunun cevabi bu. Tabi eger soyledigimin yanlis oldugunu dusunuyorsan gecikmeyi etkileyen diger ayarlarin hangileri oldugunu soyle onlara da bakalim.Sadece gecikmeyi belirleyen etken bu değil?
Mesela G/Ç zamanlayıcısı mq-deadline tercih ediliyor eğer dağıtım performans odaklı değilse, mesela bfq kullanılsa depolama bazında daha az gecikme olur. Tick rate'nin düşük tutulması peki? Yüksek olması istenir eğer latency etkense. İşlem zamanlayıcısı olarak CFQ yerine BORE, RT, TT gibileri kullanılması lazım idi. CFQ'nun varsayılan ayarları da latency için çok uygun değil ki sırf deneyip config Arch'da optimize paket yapmışlar, iki-üç "echo"luk komutu pakete sıkıştırmışlar. Madem latency için, neyi göremiyorum? Bu config girdisi hepsine bedel mi?Bu kernelin hangi amacla kullanilacagini belirliyor yani sorunun cevabi bu. Tabi eger soyledigimin yanlis oldugunu dusunuyorsan gecikmeyi etkileyen diger ayarlarin hangileri oldugunu soyle onlara da bakalim.
Peki guc kullanimi ne olacak? Laptoplar 1000Hz tick rate ile pili eritip bitirmeyecek mi?Tick rate'nin düşük tutulması peki? Yüksek olması istenir eğer latency etkense. İşlem zamanlayıcısı olarak CFQ yerine BORE, RT, TT gibileri kullanılması lazım idi.
Bunlar sadece tercih meselesi, BFQ gecikmeyi azaltmak icin degil giris cikista adaleti arttirmak icin gerekli.Mesela G/Ç zamanlayıcısı mq-deadline tercih ediliyor eğer dağıtım performans odaklı değilse, mesela bfq kullanılsa depolama bazında daha az gecikme olur.
Sunucu için bahsetmiyor muyduk? Bu bir yerde veri merkezinde çekmecede durmayacak mı? Laptopu pilde kullanan adam için latency birinci sırada mı olmalıdır?Peki guc kullanimi ne olacak? Laptoplar 1000Hz tick rate ile pili eritip bitirmeyecek mi?
Latency'i düşürmek isteyen birisi bunları uygulasa hiçbir şey kazanmaz yani? Bunlar boşuna yazıldı ve bunlar boşuna mı uygulanıyor?Bunlar sadece tercih meselesi, BFQ gecikmeyi azaltmak icin degil giris cikista adaleti arttirmak icin gerekli.