RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:

Customer is noting on their RHEL 8.2 laptop with 16 GiB of memory and no swapspace that the system hangs for an indeterminate amount of time. Through investigations, it appears the particular workload of the customer within firefox is causing firefox to consume memory gradually until the point of oom killer invocation. That being said, the time between the beginning of doing direct reclaim and forcing pretty severe major faulting activity systemwide up to the oom killer invocation can be quite variant. 


Version-Release number of selected component (if applicable):

4.18.0-193.1.2.el8_2.x86_64


How reproducible:

Pretty reliable



Steps to Reproduce:
1. Have the customer run firefox with a large number of tabs and cause pretty severe memory pressure
2. wait until system begins to hang
3.

Actual results:

System can hang for a few minutes to over an hour

Expected results:

customer expects the system to recover quickly

Additional info:

Customer has been provided a workaround with using cgroups to limit the memory usage of firefox. However, the hangs can still happen and firefox is killed more often.

Hey all, 

Closing out the BZ due to lack of response from the customer. Thank you all for the help internally on this matter.