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. İlginç olan kısım geçiş yapmak değil — o iki komut. İlginç olan kısım 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. Ve "eşiğin yakını" 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 — bir termostatın hedef sıcaklığın çevresinde sürekli açılıp kapanmamasını sağlayan aynı 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.

Açıkça söylenmesi gereken sonuç şu: 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, sonra düzeltilecek bir kusur değil — servisi sessiz kılan ö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ğu anlamına gelir; on altı çekirdekli bir iş istasyonunda makinenin büyük ölçüde boşta olduğu anlamına gelir. Ham yüke göre yazılmış bir yapılandırma dosyasının kurulduğu her makine için yeniden ayarlanması gerekirdi — ki pratikte bu, çoğunda yanlış kalacağı anlamına gelir.

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 bilinçli ve biraz modaya aykırı bir seçim. Güç yöneten bir programda sessiz varsayılanlar kötü bir ödünç: 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 ve belirti — beklenenden hafifçe yavaş ya da hafifçe daha obur bir dizüstü — sebebine geri götürülmesi neredeyse imkânsız bir şeydir. 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 — ve ö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 — ve 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 — ve gerçek uygulamayı derleme zamanında seçen bir factory kullanıyor. Testler 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.

Bu soyutlama mimari düzen aşkına eklenmedi. Önemli olan mantığa onsuz erişilemediği için eklendi.

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.