Bug 609668
Summary: | kswapd hung in D state with fragmented memory and large order allocations | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Jon Thomas <jthomas> | ||||||
Component: | kernel | Assignee: | Larry Woodman <lwoodman> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Zhouping Liu <zliu> | ||||||
Severity: | urgent | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 5.3 | CC: | aquini, dejohnso, fhirtz, jburke, jcastillo, me, nobody+295318, pveiga, qcai, SCHAKRAB, zliu | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2011-01-13 21:39:59 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Jon Thomas
2010-06-30 19:48:17 UTC
Created attachment 428080 [details]
reproducer
Created attachment 428082 [details]
patch
There are 2 parts to this patch: ------------------------------------------------------------------------ + /* + * We put equal pressure on every zone, unless one + * zone has way too many pages free already. + */ + if (!zone_watermark_ok(zone, order, + 8*zone->pages_high, end_zone, 0)) + shrink_zone(priority, zone, &sc); ----------------------------------------------------------------------- AND ----------------------------------------------------------------------- + + /* + * Fragmentation may mean that the system cannot be + * rebalanced for high-order allocations in all zones. + * At this point, if nr_reclaimed < SWAP_CLUSTER_MAX, + * it means the zones have been fully scanned and are still + * not balanced. For high-order allocations, there is + * little point trying all over again as kswapd may + * infinite loop. + * + * Instead, recheck all watermarks at order-0 as they + * are the most important. If watermarks are ok, kswapd will go + * back to sleep. High-order users can still perform direct + * reclaim if they wish. + */ + if (sc.nr_reclaimed < SWAP_CLUSTER_MAX) + order = 0; + ----------------------------------------------------------------------- I already added the first part in RHEL5: ----------------------------------------------------------------------- * Thu Jul 22 2010 Jarod Wilson <jarod> [2.6.18-208.el5] ... - [mm] fix excessive memory reclaim from zones w/lots free (Larry Woodman) [604779] ----------------------------------------------------------------------- I will add the seconf part now. Larry ... There are 2 parts to this patch: ------------------------------------------------------------------------ + /* + * We put equal pressure on every zone, unless one + * zone has way too many pages free already. + */ + if (!zone_watermark_ok(zone, order, + 8*zone->pages_high, end_zone, 0)) + shrink_zone(priority, zone, &sc); ----------------------------------------------------------------------- AND ----------------------------------------------------------------------- + + /* + * Fragmentation may mean that the system cannot be + * rebalanced for high-order allocations in all zones. + * At this point, if nr_reclaimed < SWAP_CLUSTER_MAX, + * it means the zones have been fully scanned and are still + * not balanced. For high-order allocations, there is + * little point trying all over again as kswapd may + * infinite loop. + * + * Instead, recheck all watermarks at order-0 as they + * are the most important. If watermarks are ok, kswapd will go + * back to sleep. High-order users can still perform direct + * reclaim if they wish. + */ + if (sc.nr_reclaimed < SWAP_CLUSTER_MAX) + order = 0; + ----------------------------------------------------------------------- I already added the first part in RHEL5: ----------------------------------------------------------------------- * Thu Jul 22 2010 Jarod Wilson <jarod> [2.6.18-208.el5] ... - [mm] fix excessive memory reclaim from zones w/lots free (Larry Woodman) [604779] ----------------------------------------------------------------------- I will add the second part now. Larry ... Posted this patch to rhkernel-list: ------------------------------------------------------------- diff --git a/mm/vmscan.c b/mm/vmscan.c index 517023a..42aa6b2 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1278,6 +1278,24 @@ out: } if (!all_zones_ok) { cond_resched(); + + /* + * Fragmentation may mean that the system cannot be + * rebalanced for high-order allocations in all zones. + * At this point, if nr_reclaimed < SWAP_CLUSTER_MAX, + * it means the zones have been fully scanned and are still + * not balanced. For high-order allocations, there is + * little point trying all over again as kswapd may + * infinite loop. + * + * Instead, recheck all watermarks at order-0 as they + * are the most important. If watermarks are ok, kswapd will go + * back to sleep. High-order users can still perform direct + * reclaim if they wish. + */ + if (sc.nr_reclaimed < SWAP_CLUSTER_MAX) + order = 0; + goto loop_again; } ------------------------------------------------------------------- This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. in kernel-2.6.18-227.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html |