naive question, why is this related to ARC ?

Re #1: Initially I assume this might be due to new ARC++ specific discard logic.

Bumping priority since this leads to a pretty bad user experience, and is still present in 63.0.3239.7.

cylee: How do we determine which of the low-memory tab-killer implementations is in effect on a ChromeOS device (i.e. whether the kArcMemoryManagement is active)?

With crosh/top displaying this:

top - 11:17:10 up 4 days, 22:48,  0 users,  load average: 3.45, 2.52, 1.86
Tasks: 160 total,   1 running, 159 sleeping,   0 stopped,   0 zombie
%Cpu(s): 32.7 us,  4.9 sy,  0.0 ni, 60.9 id,  1.3 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem :  3986044 total,   267304 free,  3267300 used,   451440 buff/cache
KiB Swap:  5838928 total,  2760088 free,  3078840 used.   176424 avail Mem 

my system has definitely hit "pressure" at some point (background tabs don't load -  issue 762775 ), so I'd expect there to have been discard attempts.

If I manually trigger a discard via about:discards then the chrome log shows:

[784:784:1025/112006.448409:ERROR:device_event_log_impl.cc(156)] [11:20:06.446] Memory: tab_manager_delegate_chromeos.cc:637 List of low memory kill candidates (sorted from low priority to high priority):
... list of tabs ...
[784:784:1025/112006.466922:ERROR:device_event_log_impl.cc(156)] [11:20:06.466] Memory: tab_manager_delegate_chromeos.cc:647 Target memory to free: -626688 KB

i.e. nothing is being discarded because as far as the discarder is concerned, there is "enough" memory available (the target to free is -ve). This suggests that the target-to-free calculation is broken, and that, regardless of the target, we should probably be discarding at least one process in response to pressure notifications (ignoring the issues with the notification mechanisms, for now).

Luigi, can you route this to the appropriate person to look into the target to free issue?

I am pretty sure that what's happening here is that the "manual discard trigger" just invokes LowMemoryKillImpl(), which kills zero or more tabs depending on the "target memory to free".

The header comment for LowMemoryKillImpl() lies:

   143: // Kills a process after getting all info of tabs and apps.
   144: void LowMemoryKillImpl(TabManager::DiscardTabCondition condition,
   145:                        const TabStatsList& tab_list,

Maybe it reflects an older implementation.

I can change the logic to kill at least one tab in the situation. 

But as #4 says, the more fundamental problem is probably still the definition of "memory pressure". 

#7: Hi!  True, comment #4, first part, is also a problem, but I think it's a different problem.

It seems reasonable that the "Discard tab now" UI should force the discard of one tab no matter what the memory pressure is.  It makes it more useful for testing.

In fact maybe the text should be more explicit: "Discard the lowest-priority tab now" or similar.

I would find it useful.  IIRC, Sonny and I were equally confused by this behavior at some point.  (We should have reported it then---our bad.)

Thanks!

Seeing this issue on Chrome OS: 10032.21.0/ 63.0.3239.26 dev build. Discarding a tab from About:discards, doesn't discard anything. Only the number of 'discards this session' increments.

One problem of fixing "Discard now" is that on ChromeOS, the selected process to kill may be an app instead of a tab. If so, one can not see this happened in the existing ui of chrome://discards .

I've proposed to add a "history" section in chrome://discards .

Since we are showing Android apps in the Task Manager, would it make sense to extend this UI to include Android app kills?

This is really a question and not a disguised suggestion.  I wonder if this is the right way of doing this.  But it's consistent with the view that parts of Chrome implement what traditionally is done as separate OS components.

Discussing this right now with igo: my device is very short on RAM, I'm running a video call, and still none of my tabs (including ones that were last used ~3hrs ago) are being discarded. Manually clicking on Discard in chrome://discards has no effect - I have to pick the actual tab to discard, which then does actually discard it.

I don't even see any logging in /var/log/chrome/chrome for the tab discarder, FWIW.

If clicking "Discard" does nothing that means all tabs are being protected for one reason or another (unsaved user state, playing audio, streaming, visible, etc). Clicking "Discard" next to an actual tab ignores the various bits of protection logic.

In terms of showing ARC apps as well, fdoray@ has been refactoring TabManager to make this easier, by introducing a level of abstraction between the manager and the things being managed. We should be able to do this relatively easily soon.