現在変更されている別の（非常に一般的に使用されている）アプリケーションの特定の動作に依存するソフトウェアがいくつかあり、現在の実装は実行可能ですが、最適とは言えません。
この変更は、特にパフォーマンス監視の分野で、他の多くのアプリケーションに影響を与えた可能性があると考えており、他の多くの潜在的な問題を改善すると思われる解決策を見つけました。
残念ながら、この解決策はカーネルの変更であり（比較的単純ですが、詰め込むと影響が大きくなります）、レビューのためにカーネルパッチを提出した経験はありません。
SOの誰かが実際にパッチを提出しましたか（すべての回答に感謝しますが、プロセスを経て失敗したものから最高のものが得られると思います）？あなたはそれを受け入れましたか（アランコックスらがSOにぶら下がっている可能性は何ですか）？
従うべき正しいプロセスは何ですか？Linusには、あなたが彼に届く前に通過することになっている保護者の幹部がいることを知っているので、私はLinusに電子メールを送信するつもりはありません。カーネルの特定のセクションの責任者を見つけるにはどうすればよいですか。
カーネルの世界で聞いたことのない人が貢献できると思うのは楽観的すぎるかもしれませんが、知りたいと思います。
詳細を編集：
この変更は、実際にはパフォーマンスのバグによるものではなく、プロセスの終了時に書き込まれる（現在の）プロセスアカウンティングエントリの改善（私の見解では）です。
Websphere App Server（ああ、IBM、彼らの小さな心を祝福する）はそれが行うことを変えました。JVMは、エントリが書き込まれるように定期的に終了し、それをチャージバックに使用できました。これで、JVMが数か月間放置されます。つまり、定期的にWASを強制的に停止しない限り、データをタイムリーに利用できなくなります。どういうわけか、IBMのソフトウェアグループが私たちのためにソフトウェアを修正するつもりはないと思います:-)。いずれにせよ、他の長期的なプロセスに役立つ機能かもしれないと私は信じています。
現在、タイプ3プロセスアカウンティングレコードは、プロセスの終了時に書き込まれます。私たちが見ているのは、プロセスがまだアクティブである間にタイプNレコードを定期的に書き込むメカニズムであり、最後の書き込み以降の数値を示します（または、これが初めて）。チャージバックまたはパフォーマンス監視アプリケーションは、タイプ3レコード（完全に変更されていない）または暫定タイプNレコードのいずれかを使用することを選択できます。現在の回避策は、特定のプロセスについて/ proc / PID / statを監視することですが、実際のプロセスアカウンティングとうまく統合されていないため、これは恐ろしい問題です。
頻繁である必要はありませんが（24時間で満足です）、現在プロセスexit（）でのみ実行されている作業は、プロセスコンテキストスイッチで時折実行する必要があるため、パフォーマンスに影響を与える可能性があります。Linus et alは、コードの影響が大きい領域である可能性があるため、そのアイデアを好まない可能性があります（最後の書き込みから24時間経過したかどうかを確認する場合でも、書き込みが遅すぎる可能性があります）。
それでも、これまでのすべての回答に感謝します。数日お待ちください。ベストアンサーを受け入れます。