Präemptives Multitasking-Kernel-Patch
- feltel
- Webmaster
- Beiträge: 10377
- Registriert: 20.12.2001 13:08:23
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Leipzig, Germany
-
Kontaktdaten:
Präemptives Multitasking-Kernel-Patch
Hat jemand schon den o.g. Patch, den es unter http://kpreempt.sourceforge.net herunterzuladen gibt, im Einsatz? Wie ist danach das Reaktionsverhalten des Systems?
Wenn nix dagegen spricht, dann würde ich den nämlich bei mir einsetzen.
Wenn nix dagegen spricht, dann würde ich den nämlich bei mir einsetzen.
- feltel
- Webmaster
- Beiträge: 10377
- Registriert: 20.12.2001 13:08:23
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Leipzig, Germany
-
Kontaktdaten:
Original-Zitat:
... werds mir heute mal compilieren.
Demzufolge würde der Kernel mit Patch mehrere Prozesse gleichzeitig abarbeiten und dadurch würde sich die Antwortzeit und das Antwortverhalten des Kernels verbessern.This patch enables a preemptible kernel, which reduces the latency of the kernel. It allows processes to be preempted even if in kernel mode.
The design used is to allow a task to be preempted anywhere within the kernel, using spinlocks as markers for non-preemptibility regions. The resulting system response is greatly increased, with measured average latencies under 1ms.
... werds mir heute mal compilieren.
-
- Beiträge: 462
- Registriert: 04.01.2002 18:27:23
- Wohnort: Burgfarrnbach (Fürth/Nürnberg)
-
Kontaktdaten:
ich hatte ihn ne zeit im einsatz kann nichts negatives drüber sagen. Die verbesserungen sind allerdings auch nicht gewaltig
Die USA sind direkt von der Barbarei in die Dekadenz übergegangen, ohne den Umweg über die Zivilisation zu nehmen.
-Joachim Fernau
roarin@amessage.de
-Joachim Fernau
roarin@amessage.de
und wie isses ?feltel hat geschrieben:Original-Zitat:Demzufolge würde der Kernel mit Patch mehrere Prozesse gleichzeitig abarbeiten und dadurch würde sich die Antwortzeit und das Antwortverhalten des Kernels verbessern.This patch enables a preemptible kernel, which reduces the latency of the kernel. It allows processes to be preempted even if in kernel mode.
The design used is to allow a task to be preempted anywhere within the kernel, using spinlocks as markers for non-preemptibility regions. The resulting system response is greatly increased, with measured average latencies under 1ms.
... werds mir heute mal compilieren.
ich habe den patch schon laengere zeit im einsatz und benutze ihn
auch immernoch. mir ist noch nichts negatives aufgefallen - auch die
stabilität ist super. dem empfinden nach ist das system etwas reaktionsfreudiger. es kann aber auch nur so ein gefuehl sein
wenn man den benchmark-tests glaubt - soll es aber was bringen.
gruss guddl
auch immernoch. mir ist noch nichts negatives aufgefallen - auch die
stabilität ist super. dem empfinden nach ist das system etwas reaktionsfreudiger. es kann aber auch nur so ein gefuehl sein
wenn man den benchmark-tests glaubt - soll es aber was bringen.
gruss guddl
werds morgen dann au mal mit 2.4.18 probierenfeltel hat geschrieben:Hab den Patch zusammen mit Kernel 2.4.18 jetzt seit ein paar Tagen im Einsatz. Bis jetzt kann ich zumindest nix negatives darüber berichten. An der Gesamtperformance des Systems hat sich nach meinem empfinden wenig geändert, vielleicht laufen einige Sachsen jetzt ein wenig "runder".
Kleiner Hinweis am Rande...
Linux arbeitet bereits mit präemptiven Multi-Tasking(User-Mode). (Ein Scheduler, der dafür sorgt, das jeder Prozess für eine gewisse Zeit CPU-Zeit erhält und dann sich dem nächsten Prozess zuwendet.)
Gleichzeitg kann Prinzipbedingt recht wenig in einem Rechner laufen. Allerdings geschieht die serielle Verarbeitung derart schnell, daß man das Gefühl hat, es läuft gleichzeitig. Mit dem Befehl 'nice' kann man z.B. das Verhalten des Schedulers verändern, der die CPU-Zeit zuweist. Ein Prozess, kommt dann häufiger oder weniger häufig an die Reihe und erhält damit mehr oder weniger CPU-Zeit.
Im Kernel-Mode gilt dagegen ein etwas anderes Prinzip. Kernel-Module erhalten Ihre CPU-Zeit, wenn sie meinen welche zu brauchen und geben diese frei, wenn sie keine mehr benötigen. (Nicht ganz so schlimm wie das kooperative Multitasking in MacOS 9 und abwärts oder Win 3.11 aber ähnlich.) Daher kann ein wildgewordenes Kernel-Modul einen Rechner lahmlegen. Der Patch wendet nun das selbe Verfahren auch im Kernel-Mode an und ermöglicht so, je nach System, eine subjektiv angenehmeres Arbeiten, weil ein Kernel-Modul sich keine CPU-Zeit mehr reservieren kann und mit den anderen Programmen gleichgestellt sind. => Die Anwendungen reagieren "schneller". z.B. Festplattenkopieraktionen mit nicht DMA-Platten, die sonst ewig CPU-Zeit fraßen, stören nicht mehr ganz stark beim arbeiten.
Debian HURD verfolgt dieses Prinzip bis zum Ende und läßt Kernel-Module (z.B. Treiber) grundsätzlich nur noch im User-Mode laufen. Das hat den Vorteil, daß ein wildgewordener Treiber das Gesamtsystem nicht beeinträchtigen kann.
nur so am Rande
[-1]
Linux arbeitet bereits mit präemptiven Multi-Tasking(User-Mode). (Ein Scheduler, der dafür sorgt, das jeder Prozess für eine gewisse Zeit CPU-Zeit erhält und dann sich dem nächsten Prozess zuwendet.)
Gleichzeitg kann Prinzipbedingt recht wenig in einem Rechner laufen. Allerdings geschieht die serielle Verarbeitung derart schnell, daß man das Gefühl hat, es läuft gleichzeitig. Mit dem Befehl 'nice' kann man z.B. das Verhalten des Schedulers verändern, der die CPU-Zeit zuweist. Ein Prozess, kommt dann häufiger oder weniger häufig an die Reihe und erhält damit mehr oder weniger CPU-Zeit.
Im Kernel-Mode gilt dagegen ein etwas anderes Prinzip. Kernel-Module erhalten Ihre CPU-Zeit, wenn sie meinen welche zu brauchen und geben diese frei, wenn sie keine mehr benötigen. (Nicht ganz so schlimm wie das kooperative Multitasking in MacOS 9 und abwärts oder Win 3.11 aber ähnlich.) Daher kann ein wildgewordenes Kernel-Modul einen Rechner lahmlegen. Der Patch wendet nun das selbe Verfahren auch im Kernel-Mode an und ermöglicht so, je nach System, eine subjektiv angenehmeres Arbeiten, weil ein Kernel-Modul sich keine CPU-Zeit mehr reservieren kann und mit den anderen Programmen gleichgestellt sind. => Die Anwendungen reagieren "schneller". z.B. Festplattenkopieraktionen mit nicht DMA-Platten, die sonst ewig CPU-Zeit fraßen, stören nicht mehr ganz stark beim arbeiten.
Debian HURD verfolgt dieses Prinzip bis zum Ende und läßt Kernel-Module (z.B. Treiber) grundsätzlich nur noch im User-Mode laufen. Das hat den Vorteil, daß ein wildgewordener Treiber das Gesamtsystem nicht beeinträchtigen kann.
nur so am Rande
[-1]
He who work root can fell trees and knowledge is no substitute for experience.