DDOGreen Güç Tasarrufuna Ne Zaman Geçeceğine Nasıl Karar Veriyor

DDOGreen, bir makinenin ne kadar meşgul olduğunu izleyip işletim sistemini yüksek performans ve güç tasarrufu profilleri arasında taşıyan küçük bir servis. Linux'ta tlp'yi sürüyor, Windows'ta güç planlarını değiştiriyor. Geçiş yapmak işin kolay tarafı, topu topu iki komut. Asıl mesele ne zaman geçileceğine karar vermek ve geçmemek konusunda disiplinli olmak.

Mod titremesi sorunu

Akla ilk gelen tasarımı düşünün: tek eşik. Yük %50'nin üzerindeyse performans modu, altındaysa güç tasarrufu. Şimdi kabaca yarı yükte duran bir makineyi hayal edin: birkaç sekmeli bir tarayıcı, arka planda dizin oluşturan bir dil sunucusu, olağanüstü bir şey yok. Yük her birkaç saniyede sınırın bir tarafından diğerine geçer.

Her geçiş bir mod değişimi tetikler ve mod değişimi bedava değildir. Çekirdek ve firmware düzeyinde bir dizi parametre yeniden uygulanır: CPU yönetici politikası, enerji-performans tercihi, SATA bağlantı güç yönetimi, PCI aygıtlarında çalışma zamanı güç yönetimi, kablosuz güç tasarrufu. Bunu bir kez yapmak ucuzdur. Her birkaç saniyede bir yapmak, tasarruf edilenden fazla enerji harcar ve kullanıcı bunu takılma olarak fark eder. Makine, kullanıcının işinden başka bir şeyle uğraşıyormuş gibi hissettirir.

Tek eşik, eşiğin yakınında seyreden her iş yükü için bu davranışı garanti eder. "Eşiğin yakını" ise istisnai bir durum değil, sıradan masaüstü kullanımı tam olarak böyle görünür.

İki eşik ve bir ölü bant

Çözüm histerezis, yani bir termostatın hedef sıcaklığın çevresinde sürekli açılıp kapanmamasını sağlayan fikir. DDOGreen tek eşik yerine iki eşik alıyor:

• Yük high_performance_threshold değerinin üzerindeyse → performans moduna geç.
• Yük power_save_threshold değerinin altındaysa → güç tasarrufu moduna geç.
• Yük ikisinin arasındaysa → hiçbir şey yapma. Bulunduğun modda kal.

Ortadaki bölge bir ölü bant ve tasarımın tamamı bundan ibaret. Eşikler örneğin %30 ve %70 olduğunda, yarı yükte gezinen bir makine hangi moddaysa onda kalır. Performans moduna geçmesi için iş yükünün gerçekten %70'i aşması, güç tasarrufuna dönmesi için yükün gerçekten %30'un altına inmesi gerekir. Sıradan gürültü artık iki sınıra da ulaşamaz.

Bunun açıkça söylenmesi gereken bir sonucu var. DDOGreen her zaman mevcut yükünün işaret ettiği modda çalışmaz. Aynı %50 yükteki iki makine farklı modlarda olabilir, çünkü oraya zıt yönlerden gelmişlerdir. Bu sonradan düzeltilecek bir kusur değil. Servisi sakin tutan özelliğin kendisi.

Neden ham yük değil, çekirdek başına yük ortalaması

DDOGreen bir dakikalık yük ortalamasını okuyup eşiklerle karşılaştırmadan önce CPU çekirdek sayısına bölüyor. Yapılandırma bu yüzden çekirdek başına yük olarak ifade ediliyor: 0.70, çekirdek başına bir çekirdeğin %70'i kadar iş anlamına geliyor.

Bu önemli, çünkü ham yük ortalaması makineler arasında karşılaştırılabilir bir sayı değil. Dört çekirdekli bir dizüstünde 4.0 yükü her çekirdeğin dolu olduğunu gösterir. On altı çekirdekli bir iş istasyonunda ise aynı sayı makinenin büyük ölçüde boşta olduğunu gösterir. Ham yüke göre yazılmış bir yapılandırma dosyasının kurulduğu her makine için yeniden ayarlanması gerekirdi. Pratikte bu, dosyanın çoğu makinede yanlış kalması demek.

Normalize etmek kayıtları da okunabilir kılıyor. Servis, mevcut çekirdek sayısı için hesapladığı mutlak eşiği ve bunu türettiği yüzdeyi birlikte yazıyor. Böylece bir makine beklenmedik davrandığında eşiklerin istediğiniz yere düşüp düşmediğini hemen görebiliyorsunuz.

Bir dakikalık pencerenin kendisi de histerezisin parçası. Daha kısa bir ortalama tek bir derleme işlemine tepki verirdi. Bir dakika boyunca süren yük ise "kullanıcı gerçekten çalışıyor" için makul bir gösterge.

Varsayılan değer vermeyi reddetmek

DDOGreen'in gömülü hiçbir varsayılan değeri yok. Yapılandırma dosyasında monitoring_frequency, high_performance_threshold veya power_save_threshold eksikse, servis hangisinin eksik olduğunu kayda yazıyor ve başlamayı reddediyor.

Bu, kuran kişiye yük bindiren bir şey değil, çünkü paketler çalışan bir yapılandırma dosyası kuruyor. Mesele daha dar: servis, kimsenin yazmadığı bir değeri asla kendiliğinden uydurmuyor.

Bu bilinçli ve biraz modaya aykırı bir seçim. Güç yöneten bir programda sessiz varsayılanlar kötü bir takas. Bir anahtar adındaki yazım hatası, servisin operatörün hiç seçmediği değerlerle mutlu mesut çalışmasına yol açar. Ortaya çıkan belirtiyi, yani beklenenden hafifçe yavaş ya da hafifçe daha obur bir dizüstünü, sebebine geri götürmek neredeyse imkânsızdır. Başlangıçta yüksek sesle hata vermek, bir muammayı tek satırlık bir kayda dönüştürür.

Doğrulama varlık kontrolüyle bitmiyor. Her değer aralık denetiminden geçiyor (monitoring_frequency 1–300 saniye, high_performance_threshold 0.1–1.0, power_save_threshold 0.05–0.9) ve ardından iki eşik birbirine karşı denetleniyor: power_save_threshold, high_performance_threshold değerinden kesinlikle küçük olmak zorunda.

Kendini asıl amorti eden denetim bu son madde. Ters çevrilmiş eşikler tek tek geçerli sayılardır, dolayısıyla hiçbir alan bazlı doğrulama onları yakalayamaz, üstelik ölü bandı yok ederek tasarımın önlemek için var olduğu titremeyi bizzat üretirler. Yalnızca iki alan arasında anlamı olan bir kısıt, o iki alan arasında denetlenmek zorundadır.

Çağırdığınız araca güvenmemek

Linux'ta mod değiştirmek tlp ac veya tlp bat çalıştırmak demek. Akla ilk gelen uygulama süreç çıkış kodunu kontrol edip yoluna devam eder.

Bunun güvenilir olmadığı ortaya çıktı: TLP hatayı çıkış durumu üzerinden tutarlı biçimde bildirmiyor. Bu yüzden DDOGreen komutun birleşik çıktısını yakalayıp inceliyor, yalnızca dönüş değerine güvenmiyor. Ayrıca güç yönetebileceğini iddia etmeden önce tlp'nin sistemde bulunup bulunmadığını kontrol ediyor.

Bunun güç yönetiminin çok ötesine geçen genel bir dersi var. Harici bir araca komut gönderdiğinizde, o aracın hata bildirme biçimi arayüzünün parçasıdır ve bu arayüzü geleneklere uyduğunu varsaymak yerine deneyerek doğrulamanız gerekir. Başarısız bir komutu başarılı sanan bir servis, hiç girmediği bir modu bildirir. Bu çökmekten daha kötüdür, çünkü kayıtlar sorunsuz görünecektir.

Kararın test edilebilmesi için tasarlamak

Güç yönetimi testlere düşmandır. Gerçek davranış root yetkisine, TLP'nin ya da Windows güç planlarının kurulu olmasına ve istediğiniz anda üretemeyeceğiniz bir sistem yüküne bağlıdır. Doğrudan test etmeye kalkarsanız yalnızca tek bir geliştiricinin dizüstünde çalışan bir test paketi elde edersiniz.

DDOGreen her platform etkileşimini dar bir arayüzün arkasına koyuyor: yük okumak için ISystemMonitor, mod uygulamak için IPowerManager, ayrıca sinyal işleme ve platform yardımcıları için arayüzler. Gerçek uygulamayı derleme zamanında bir factory seçiyor, testler de bunların yerine mock koyuyor.

Bu dikiş yerinde olunca eşik mantığı sıradan bir birim testine dönüşüyor: bir yük dizisi ver, hangi mod geçişlerini istediğini doğrula. En çok önem taşıyan senaryolar da tam olarak gerçek donanımda üretilmesi pratik olmayanlar: ölü bandın içinde salınan yük, bir sınırı tam olarak bir kez geçen yük, servis başlamadan reddedilen ters yapılandırma.

Mimari düzen aşkına eklenmiş bir soyutlama değil bu. Önemli olan mantığa onsuz erişilemediği için orada duruyor.

DDOGreen açık kaynak ve Linux ile Windows için paketleniyor. Burada anlatılan eşik mantığı etkinlik izleyicisinde, yapılandırma doğrulaması ise config yükleyicisinde duruyor. Gerçeğini okumak isterseniz: github.com/abkulakli/ddogreen.