<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - MemoryPressureHandler doesn't work if cgroups aren't present in Linux"
href="https://bugs.webkit.org/show_bug.cgi?id=155255#c18">Comment # 18</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - MemoryPressureHandler doesn't work if cgroups aren't present in Linux"
href="https://bugs.webkit.org/show_bug.cgi?id=155255">bug 155255</a>
from <span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=155255#c15">comment #15</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=155255#c13">comment #13</a>)
>
> > > Source/WebCore/platform/linux/MemoryPressureHandlerLinux.cpp:149
> > > + sleep(s_pollingIntervalInSeconds);
> > > + } while (true);
> >
> > I'm not happy with this either, but I have no idea how to do this if meminfo
> > is not pollable. Note that there's one memory pressure handler per process .
>
> We can use a larger polling interval (5 sec?) and wider memory threshold
> margins so that we trigger the pressure condition earlier without needing
> such a high monitoring frequency. Actually, I thing that the current
> thresholds for remaining memory of 300MB (non critical) and 100MB (critical)
> are wide enough.
>
> About battery consumption, take into account the relative expense of
> "opening a text file, parsing its first lines and closing it". What can it
> be, some milliseconds? I can't believe it's so expensive compared to the
> huge amount of time (in terms of CPU time scale) that the thread is going to
> be idle.</span >
The problem is precisely that the thread is never going to be idle, it's going to wake up every second. It's not only a matter of what you do when you wake up, it's just that you are waking up every second. I've seen patches in embedded devices to fix battery drain that simply removed loops like this one. If there's no other way to do this, we should figure out if it's possible to disable this while there's no activity, or pages are all hidden, etc.</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>