<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [GTK] Since the memory pressure relief has been activated, my disk has a high usage and the desktop stalls"
   href="https://bugs.webkit.org/show_bug.cgi?id=164052#c5">Comment # 5</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [GTK] Since the memory pressure relief has been activated, my disk has a high usage and the desktop stalls"
   href="https://bugs.webkit.org/show_bug.cgi?id=164052">bug 164052</a>
              from <span class="vcard"><a class="email" href="mailto:cgarcia&#64;igalia.com" title="Carlos Garcia Campos &lt;cgarcia&#64;igalia.com&gt;"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
        <pre>(In reply to <a href="show_bug.cgi?id=164052#c4">comment #4</a>)
<span class="quote">&gt; (In reply to <a href="show_bug.cgi?id=164052#c3">comment #3</a>)
&gt; &gt; (In reply to <a href="show_bug.cgi?id=164052#c2">comment #2</a>)
&gt; &gt;&gt; The same workload / number of tabs that used to work quite well without the
&gt; &gt;&gt; memory pressure relief is now swapping. So I doubt WK is really running out
&gt; &gt;&gt; of memory.
&gt; &gt; 
&gt; &gt; That's a different issue though. This bug is about running the memory
&gt; &gt; pressure handler several times when the memory situation is critical,
&gt; &gt; assuming the measure is correct. Another issue is that we might be
&gt; &gt; calculating the memory available wrongly, or that we are triggering the
&gt; &gt; handler too early (we currently use 90%). Note also that the memory pressure
&gt; &gt; doesn't monitors the webkit memory, but the system memory, so it's possible
&gt; &gt; that it's not WebKit the one causing the high memory usage, but we try to
&gt; &gt; help in any case by freeing caches, etc. In those cases it's common that we
&gt; &gt; end up freeing very little memory or nothing, we could check that and
&gt; &gt; increase the interval to install the handler again.
&gt; 
&gt; I can reliably make it swap with just one terminal (running screen over SSH)
&gt; and epiphany with a dozen tabs. The tabs have a bunch of bugzilla.gnome.org
&gt; pages, and some other websites. The tabs act as a TODO list, so I have had
&gt; them for a while and it wasn't a problem before.
&gt; 
&gt; It can always be some other thing that is eating away memory. However, it
&gt; seems unlikely since this happens just after opening some new tabs on a
&gt; freshly booted machine.
&gt; 
&gt; &gt; If you think we are measuring wrong, or that 90% is too early, file a new
&gt; &gt; bug report, please.
&gt; 
&gt; Or I can wait for this bug to be fixed and see if it also addresses my
&gt; problem. :)</span >

Since you can reliably reproduce it, it would be very useful for us to know some information to fix this bug. Could you please check the current memory usage of the system when this happens? Check what gnome-system-monitor says, and what is more important the contents of /proc/meminfo at that moment.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>