This bug was fixed in the package webbrowser-app -
0.23+16.04.20161028-0ubuntu2
---
webbrowser-app (0.23+16.04.20161028-0ubuntu2) xenial; urgency=medium
* SRU for selected bug fixes:
- LP: #1565055: support for google hangouts
- LP: #1573017: SAML detection logic broken in w
Tested and verified in an up-to-date xenial amd64 VM, with webbrowser-
app 0.23+16.04.20161028-0ubuntu2.
The VM has 768MB of memory, and after opening a number of memory-hungry
tabs, I can see that the oldest ones are being unloaded to free up some
memory, instead of the system taking down the ent
Hello Victor, or anyone else affected,
Accepted webbrowser-app into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/webbrowser-
app/0.23+16.04.20161028-0ubuntu2 in a few hours, and then in the
-proposed repository.
Please help us by testing thi
Tested and verified in an up-to-date xenial amd64 VM, with webbrowser-
app 0.23+16.04.20161028-0ubuntu1.
The VM has 784MB of memory, and after opening a number of memory-hungry
tabs, I can see that the oldest ones are being unloaded to free up some
memory, instead of the system taking down the ent
Hello Victor, or anyone else affected,
Accepted webbrowser-app into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/webbrowser-
app/0.23+16.04.20161028-0ubuntu1 in a few hours, and then in the
-proposed repository.
Please help us by testing thi
** Also affects: webbrowser-app (Ubuntu Xenial)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576639
Title:
memory threshold is too high
To manage notif
** Description changed:
When opening new tabs in the browser, it decides if it should close
existing ones based on level of free memory available in the system. My
understanding is that this is currenly set to 30% percentage of memory
in the device.
There are two issues with this appr
** Branch linked: lp:~osomon/webbrowser-app/xenial-sru-1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576639
Title:
memory threshold is too high
To manage notifications about this bug go to:
http
** Changed in: canonical-devices-system-image
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576639
Title:
memory threshold is too high
To manage notifi
This bug was fixed in the package webbrowser-app -
0.23+16.04.20160509.3-0ubuntu1
---
webbrowser-app (0.23+16.04.20160509.3-0ubuntu1) xenial; urgency=medium
[ CI Train Bot ]
* Resync trunk.
[ Olivier Tilloy ]
* Fine-tune the custom memory-pressure handler, from data gathered
@JOnathanJOnes: this is already the case: unloaded tabs are being
serialized on disk. There are several other factors at play that might
trigger some network activity when reloading a tab though, depending on
the cache policy requested by the server, and more generally the dynamic
nature of the pag
What if all unloaded tabs are saved as a binary file on the hard disk
and loaded from the hard disk if the user switches back to that tab. The
advantage would be that there is no need to reload the tab from the net.
Is that a way to solve it?
--
You received this bug notification because you are
** Changed in: canonical-devices-system-image
Status: In Progress => Fix Committed
** Changed in: webbrowser-app (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.
That was an easy one: an incorrect type for the timestamp meant that the
value was capped at MAX_INT and never changed, so the first tab in the
list was always selected for unloading. This is now fixed in the linked
branch.
--
You received this bug notification because you are a member of Ubuntu
And 200MB seems to work well on the E4.5, so 20% seems to be a
reasonable threshold overall.
However I’m still seeing an issue with the memory pressure mechanism: on
a tablet (wide layout) the least recently viewed tabs are unloaded first
as expected, but on a phone (narrow layout), the most recen
400MB works much better as a threshold on my M10 indeed. However I’m
seeing something fishy: whenever the browser unloads a background tab to
free up some memory, a small amount of memory is indeed reclaimed
(usually less than 100MB), but the browser process continues to use up a
lot of memory. Whe
Testing the linked branch on M10, and I got several occurrences of the
OOM killer killing the browser app while it was the foreground app,
before the browser got a chance to unload any background tab.
That happens more often when there are fewer apps in the background
(because the OOM killer has f
** Branch linked: lp:~osomon/webbrowser-app/fine-tune-memory-pressure-
handler
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576639
Title:
memory threshold is too high
To manage notifications abou
** Changed in: webbrowser-app (Ubuntu)
Status: Confirmed => In Progress
** Changed in: canonical-devices-system-image
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpa
And to follow up on previous comments: with the current approach we’ll
never be able to fully prevent the OOM killer from kicking in (nor would
it be desirable), what we need is an acceptable threshold that gives
good results (prevents the browser from being killed while in the
foreground most of t
I did some extensive stress-testing on an M10, an MX4 and a E4.5, all
running the latest rc-proposed image. I launched a number of
applications (some native, some webapps) in the background, and then
opened a number of tabs in the browser app (with the mechanism to unload
tabs temporarily disabled)
An approach similar to what we currently do in the browser has been
proposed for WebKit, as an alternative on configurations where memory
cgroups are not available, see
https://bugs.webkit.org/show_bug.cgi?id=155255.
However only MemFree is considered, and there are two (arbitrary) thresholds:
-
First of all: I agree with the original bug report, relying on % of
total system memory is likely to over- or under-estimate the actual
memory situation. A short-term solution would be to select a fixed
threshold in accordance with the OOM setup configured on our kernels,
thus avoiding the issues p
The system OOM killer typically kicks in when it’s running out of memory
(including swap).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576639
Title:
memory threshold is too high
To manage notifi
Hi
I'm not the best person to comment on this issue except for the fact
that this but also affects me, but shouldn't the kernel start swapping
memory?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/157
I raised the threshold to 300MB, but this time the system OOM kicked in
while the browser was reporting 345512KB free memory (337MB), which
roughly translates to 17% free memory on that device.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
I’ve changed the threshold to 100MB and tested on my M10.
This is too low, the system OOM killer kicks in before the browser gets a
chance to unload background tabs:
May 2 16:25:39 ubuntu-phablet kernel: [ 3173.400686]
(0)[54:kswapd0]lowmemorykiller: Killing 'webbrowser-app' (7341), adj 1,
sco
Lets try with 100MB and get some mileage on proposed
** Also affects: canonical-devices-system-image
Importance: Undecided
Status: New
** Changed in: canonical-devices-system-image
Importance: Undecided => High
** Changed in: canonical-devices-system-image
Status: New => Conf
** Summary changed:
- memory treshhold is too high
+ memory threshold is too high
** Changed in: webbrowser-app (Ubuntu)
Status: New => Confirmed
** Changed in: webbrowser-app (Ubuntu)
Assignee: (unassigned) => Olivier Tilloy (osomon)
--
You received this bug notification because y
29 matches
Mail list logo
