<story><title>Using GPT-3 for plain language incident root cause from logs</title><url>https://www.zebrium.com/blog/using-gpt-3-with-zebrium-for-plain-language-incident-root-cause-from-logs</url></story><parent_chain></parent_chain><comment><author>wzdd</author><text>It&amp;#x27;s nice to get the textual description, but pretty much every specific detail of the extended explanation teased out at the end includes things which are more or less incorrect but which nonetheless sound very believable. In essence, what happened at the end was GPT-3 was asked to write an OOM-killer-inspired story. I think this should be a cautionary tale against trying to use GPT-3 to provide commentary beyond a high-level summary.&lt;p&gt;This isn&amp;#x27;t a slight against the short-summary technique, which seems very cool.&lt;p&gt;Details: oom_adj isn&amp;#x27;t a flag, it&amp;#x27;s an int which can disable OOM on a per-process-leader basis but can also but can also be used to reduce the &amp;quot;badness&amp;quot; of a process when considering what to kill. Oom_adj is also deprecated and has been replaced by oom_score_adj. The OOM algorithm isn&amp;#x27;t called RSS. It doesn&amp;#x27;t seem to have been explicitly named, but the function which performs the key calculation is named oom_badness. This function assigns an integer &amp;quot;badness&amp;quot; to each process. A process&amp;#x27; resident set size &lt;i&gt;is&lt;/i&gt; an important part of calculating badness, but it&amp;#x27;s affected by several other factors (what they are depends on kernel version but they include the adjustment parameter). RSS is not (part of) the OOM calculation &amp;quot;by default&amp;quot; -- it&amp;#x27;s always included unless OOM is disabled entirely. RSS isn&amp;#x27;t a comparison of reserved physical memory against current virtual size, it&amp;#x27;s just the amount of RAM currently occupied by a process (i.e. not in swap or on disk). The OOM killer doesn&amp;#x27;t compare RSS against virtual size. RSS doesn&amp;#x27;t trigger the OOM killer. RSS isn&amp;#x27;t an algorithm.&lt;p&gt;Another interesting aspect of this, of course, is that GPT-3 likely wasn&amp;#x27;t trained on any specific kernel version, but on a large number of versions depending on which part of the Internet it happened to be reading. This means that it probably can&amp;#x27;t give a good account of any single version of fast-changing parts of the kernel like the OOM killer.&lt;p&gt;Source: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;torvalds&amp;#x2F;linux&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;mm&amp;#x2F;oom_kill.c&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;torvalds&amp;#x2F;linux&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;mm&amp;#x2F;oom_kill.c&lt;/a&gt;</text></comment>
<story><title>Using GPT-3 for plain language incident root cause from logs</title><url>https://www.zebrium.com/blog/using-gpt-3-with-zebrium-for-plain-language-incident-root-cause-from-logs</url></story><parent_chain></parent_chain><comment><author>bbu</author><text>This is pretty cool! 
However, these two samples are very simple to solve. I&amp;#x27;d love an &amp;quot;AI&amp;quot; to find root causes for problems that are not obvious.
Just throw the whole log collection at it and let it solve all the issues. One can dream ;)</text></comment>