Wie kann man einen potenziellen Patch für den Linux-Kernel einreichen?

Question

Wir haben einige Software, die sich auf ein bestimmtes Verhalten einer anderen ( muy häufig verwendete) Anwendung, die sich nun geändert hat, so dass unsere derzeitige Implementierung zwar praktikabel, aber nicht optimal ist.

Wir glauben, dass diese Änderung eine Reihe anderer Anwendungen, insbesondere im Bereich der Leistungsüberwachung, beeinträchtigt haben könnte, und wir haben eine Lösung gefunden, die unserer Meinung nach eine ganze Reihe anderer potenzieller Probleme verbessern wird.

Leider handelt es sich bei der besagten Lösung um eine Kernel-Änderung (relativ einfach, aber mit großen Auswirkungen, wenn wir es vermasseln), und wir haben keine Erfahrung mit der Einreichung von Kernel-Patches zur Überprüfung.

Hat irgendjemand von SO tatsächlich einen Patch eingereicht (obwohl ich alle Antworten zu schätzen weiß, vermute ich, dass die besten Antworten von denjenigen kommen, die den Prozess bereits durchlaufen haben, auch wenn sie nicht erfolgreich waren)? Wurde er angenommen (wie groß sind die Chancen, dass Alan Cox und Co. auf SO herumhängen)?

Welches ist das richtige Verfahren? Ich habe nicht die Absicht, eine E-Mail an Linus zu schicken, da ich weiß, dass er einen Kader von Beschützern hat, die man durchlaufen muss, bevor man zu ihm gelangt. Wie kann ich herausfinden, wer für einen bestimmten Abschnitt des Kernels verantwortlich ist?

Vielleicht bin ich zu optimistisch, wenn ich glaube, dass jemand, von dem die Welt des Kerns noch nie etwas gehört hat, einen Beitrag leisten kann, aber ich würde es gerne herausfinden.

---

EDIT mit mehr Details:

Die Änderung bezieht sich nicht auf einen Leistungsfehler, sondern auf eine Verbesserung (meiner Meinung nach) der Prozessbuchhaltungseinträge, die (derzeit) geschrieben werden, wenn ein Prozess beendet wird.

Websphere App Server (ach, IBM, Gott segne ihre kleinen Herzen) hat seine Funktionsweise geändert. Früher wurden JVMs regelmäßig beendet, damit ihre Einträge geschrieben wurden und wir diese für die Rückbuchung verwenden konnten. Jetzt lässt sie JVMs monatelang herumliegen, was bedeutet, dass die Daten nicht rechtzeitig verfügbar sind, es sei denn, wir zwingen WAS regelmäßig zum Herunterfahren. Irgendwie glaube ich nicht, dass die Software Group von IBM ihre Software für uns reparieren wird :-). Auf jeden Fall glaube ich, dass es eine nützliche Funktion für andere langlebige Prozesse sein kann.

Derzeit werden Typ-3-Prozessabrechnungsdatensätze geschrieben, wenn ein Prozess beendet wird. Was wir suchen, ist ein Mechanismus, um Typ-N-Datensätze regelmäßig zu schreiben, während ein Prozess noch aktiv ist und die Zahlen seit dem letzten Schreiben (oder dem Prozessstart, wenn dies das erste Mal ist) anzugeben. Anwendungen zur Rückverrechnung oder Leistungsüberwachung können entweder die Typ-3-Datensätze (völlig unverändert) oder die Typ-N-Zwischensätze verwenden. Die derzeitige Lösung besteht darin, /proc/PID/stat für bestimmte Prozesse zu überwachen, aber das ist ein schrecklicher Trick, da er sich nicht gut in die echte Prozessabrechnung integrieren lässt.

Es muss nicht oft sein (wir wären mit 24 Stunden zufrieden), aber es könnte eine Auswirkung auf die Leistung haben, da die Arbeit, die derzeit nur bei process exit() gemacht wird, gelegentlich beim Prozesskontextwechsel gemacht werden muss. Linus et al. mögen diese Idee vielleicht nicht, da es sich um einen Bereich des Codes handelt, der hohe Auswirkungen hat (selbst die Überprüfung, ob seit dem letzten Schreibvorgang 24 Stunden vergangen sind, könnte für sie zu langsam sein).

Trotzdem vielen Dank für die bisherigen Antworten, ich werde sehen, wie ich vorankomme. Geben Sie mir ein paar Tage und ich werde die beste Antwort akzeptieren.

Answer 1

Auf der EDIT könnte die Antwort als Fallbeispiel interessant sein. Ich denke, Ihre Anforderung ist absolut vernünftig, aber Sie haben Recht, dass sogar ein Test auf Kontextwechsel zu teuer sein könnte. Aber da der Kernel eine Timer-Implementierung hat, sehe ich nicht, warum diese nicht verwendet werden kann, um das zu vermeiden. Daher ist es in der Tat am sichersten, einen Antrag auf Verbesserung vorzuschlagen. Ich bin überrascht, dass der Vorschlag, einen Fehlerbericht statt eines Patches zu schicken, so gut passte. Sie können den Patch auch selbst modifizieren, um Timer zu verwenden, wenn Sie ihn einreichen möchten, aber trotzdem zur Diskussion bereit sein :-) Sie können sogar hinzufügen "wir haben einen lokalen Fix, aber er fügt einige Tests auf dem schnellen Pfad des Kontextwechsels hinzu, deshalb ist der Patch als Referenz beigefügt, sollte aber nicht angewendet werden". Wenn Sie Ihren eigenen Code ablehnen, wenn er als schlecht bekannt ist, vermeiden Sie harte Kritiken an dem Patch.

Die Alternative ist, einige Benchmarks durchzuführen und zu beweisen, dass es keine Auswirkungen gibt, aber wenn Timer praktikabel sind, wird dieser Code ohnehin abgelehnt, oder die Timer-Lösung selbst auszuprobieren (vielleicht gibt es etwas Besseres). Finden Sie die Benchmarks, die sie für den Kernel-Scheduler verwenden; schauen Sie sich die "aktuellen" Threads über den Patch von CFS Ingo (oder Kolivas?) an und nehmen Sie deren Benchmarks.

Was den Support angeht, so werden sich die Kernel-Entwickler nicht um den "Websphere App Server" an sich kümmern, wenn er unvernünftige Dinge tut, nicht einmal von IBM finanzierte. Aber mit meinem begrenzten Wissen über die Situationen macht das regelmäßige Herunterfahren einer JVM keinen Sinn, es scheint nur ein Weg zu sein, um ein Speicherleck/eine Instabilität zu überspielen, also muss das aktuelle Verhalten unterstützt werden.