From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271iBM180537 for ; Thu, 2 Jun 2011 02:01:44 -0500 Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 808A11ED18EE for ; Thu, 2 Jun 2011 00:01:42 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id BVnfx74hwhde5ET5 for ; Thu, 02 Jun 2011 00:01:42 -0700 (PDT) From: Dave Chinner Subject: [PATCH 03/12] vmscan: reduce wind up shrinker->nr when shrinker can't do work Date: Thu, 2 Jun 2011 17:00:58 +1000 Message-Id: <1306998067-27659-4-git-send-email-david@fromorbit.com> In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: linux-fsdevel@vger.kernel.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com RnJvbTogRGF2ZSBDaGlubmVyIDxkY2hpbm5lckByZWRoYXQuY29tPgoKV2hlbiBhIHNocmlua2Vy IHJldHVybnMgLTEgdG8gc2hyaW5rX3NsYWIoKSB0byBpbmRpY2F0ZSBpdCBjYW5ub3QgZG8KYW55 IHdvcmsgZ2l2ZW4gdGhlIGN1cnJlbnQgbWVtb3J5IHJlY2xhaW0gcmVxdWlyZW1lbnRzLCBpdCBh ZGRzIHRoZQplbnRpcmUgdG90YWxfc2NhbiBjb3VudCB0byBzaHJpbmtlci0+bnIuIFRoZSBpZGVh IGVoaW5kIHRoaXMgaXMgdGhhdAp3aGVudGVoIHNocmlua2VyIGlzIG5leHQgY2FsbGVkIGFuZCBj YW4gZG8gd29yaywgaXQgd2lsbCBkbyB0aGUgd29yawpvZiB0aGUgcHJldmlvdXNseSBhYm9ydGVk IHNocmlua2VyIGNhbGwgYXMgd2VsbC4KCkhvd2V2ZXIsIGlmIGEgZmlsZXN5c3RlbSBpcyBkb2lu ZyBsb3RzIG9mIGFsbG9jYXRpb24gd2l0aCBHRlBfTk9GUwpzZXQsIHRoZW4gd2UgZ2V0IG1hbnks IG1hbnkgbW9yZSBhYm9ydHMgZnJvbSB0aGUgc2hyaW5rZXJzIHRoYW4gd2UKZG8gc3VjY2Vzc2Z1 bCBjYWxscy4gVGhlIHJlc3VsdCBpcyB0aGF0IHNocmlua2VyLT5uciB3aW5kcyB1cCB0bwppdCdz IG1heGltdW0gcGVybWlzc2libGUgdmFsdWUgKHR3aWNlIHRoZSBjdXJyZW50IGNhY2hlIHNpemUp IGFuZAp0aGVuIHdoZW4gdGhlIG5leHQgc2hyaW5rZXIgY2FsbCB0aGF0IGNhbiBkbyB3b3JrIGlz IGlzc3VlZCwgaXQKaGFzIGVub3VnaCBzY2FuIGNvdW50IGJ1aWx0IHVwIHRvIGZyZWUgdGhlIGVu dGlyZSBjYWNoZSB0d2ljZSBvdmVyLgoKVGhpcyBtYW5pZmVzdHMgaXRzZWxmIGluIHRoZSBjYWNo ZSBnb2luZyBmcm9tIGZ1bGwgdG8gZW1wdHkgaW4gYQptYXR0ZXIgb2Ygc2Vjb25kcywgZXZlbiB3 aGVuIG9ubHkgYSBzbWFsbCBwYXJ0IG9mIHRoZSBjYWNoZSBpcwpuZWVkZWQgdG8gYmUgZW1wdGll ZCB0byBmcmVlIHN1ZmZpY2llbnQgbWVtb3J5LgoKVW5kZXIgbWV0YWRhdGEgaW50ZW5zaXZlIHdv cmtsb2FkcyBvbiBleHQ0IGFuZCBYRlMsIEknbSBzZWVpbmcgdGhlClZGUyBjYWNoZXMgaW5jcmVh c2UgbWVtb3J5IGNvbnN1bXB0aW9uIHVwIHRvIDc1JSBvZiBtZW1vcnkgKG5vIHBhZ2UKY2FjaGUg cHJlc3N1cmUpIG92ZXIgYSBwZXJpb2Qgb2YgMzAtNjBzLCBhbmQgdGhlbiB0aGUgc2hyaW5rZXIK ZW1wdGllcyB0aGVtIGRvd24gdG8gemVybyBpbiB0aGUgc3BhY2Ugb2YgMi0zcy4gVGhpcyBjeWNs ZSByZXBlYXRzCm92ZXIgYW5kIG92ZXIgYWdhaW4sIHdpdGggdGhlIHNocmlua2VyIGNvbXBsZXRl bHkgdHJhc2hpbmcgdGhlINGWbm9kZQphbmQgZGVudHJ5IGNhY2hlcyBldmVyeSBtaW51dGUgb3Ig c28gdGhlIHdvcmtsb2FkIGNvbnRpbnVlcy4KClRoaXMgYmVoYXZpb3VyIHdhcyBtYWRlIG9idmlv dXMgYnkgdGhlIHNocmlua19zbGFiIHRyYWNlcG9pbnRzIGFkZGVkCmVhcmxpZXIgaW4gdGhlIHNl cmllcywgYW5kIG1hZGUgd29yc2UgYnkgdGhlIHBhdGNoIHRoYXQgY29ycmVjdGVkCnRoZSBjb25j dXJyZW50IGFjY291bnRpbmcgb2Ygc2hyaW5rZXItPm5yLgoKVG8gYXZvaWQgdGhpcyBwcm9ibGVt LCBzdG9wIHJlcGVhdGVkIHNtYWxsIGluY3JlbWVudHMgb2YgdGhlIHRvdGFsCnNjYW4gdmFsdWUg ZnJvbSB3aW5kaW5nIHNocmlua2VyLT5uciB1cCB0byBhIHZhbHVlIHRoYXQgY2FuIGNhdXNlCnRo ZSBlbnRpcmUgY2FjaGUgdG8gYmUgZnJlZWQuIFdlIHN0aWxsIG5lZWQgdG8gYWxsb3cgaXQgdG8g d2luZCB1cCwKc28gdXNlIHRoZSBkZWx0YSBhcyB0aGUgImxhcmdlIHNjYW4iIHRocmVzaG9sZCBj aGVjayAtIGlmIHRoZSBkZWx0YQppcyBtb3JlIHRoYW4gYSBxdWFydGVyIG9mIHRoZSBlbnRpcmUg Y2FjaGUgc2l6ZSwgdGhlbiBpdCBpcyBhIGxhcmdlCnNjYW4gYW5kIGFsbG93ZWQgdG8gY2F1c2Ug bG90cyBvZiB3aW5kdXAgYmVjYXVzZSB3ZSBhcmUgY2xlYXJseQpuZWVkaW5nIHRvIGZyZWUgbG90 cyBvZiBtZW1vcnkuCgpJZiBpdCBpc24ndCBhIGxhcmdlIHNjYW4gdGhlbiBsaW1pdCB0aGUgdG90 YWwgc2NhbiB0byBoYWxmIHRoZSBzaXplCm9mIHRoZSBjYWNoZSBzbyB0aGF0IHdpbmR1cCBuZXZl ciBpbmNyZWFzZXMgdG8gY29uc3VtZSB0aGUgd2hvbGUKY2FjaGUuIFJlZHVjaW5nIHRoZSB0b3Rh bCBzY2FuIGxpbWl0IGZ1cnRoZXIgZG9lcyBub3QgYWxsb3cgZW5vdWdoCndpbmQtdXAgdG8gbWFp bnRhaW4gdGhlIGN1cnJlbnQgbGV2ZWxzIG9mIHBlcmZvcm1hbmNlLCB3aGlsc3QgYQpoaWdoZXIg dGhyZXNob2xkIGRvZXMgbm90IHByZXZlbnQgdGhlIHdpbmR1cCBmcm9tIGZyZWVpbmcgdGhlIGVu dGlyZQpjYWNoZSB1bmRlciBzdXN0YWluZWQgd29ya2xvYWRzLgoKU2lnbmVkLW9mZi1ieTogRGF2 ZSBDaGlubmVyIDxkY2hpbm5lckByZWRoYXQuY29tPgotLS0KIG1tL3Ztc2Nhbi5jIHwgICAxNCAr KysrKysrKysrKysrKwogMSBmaWxlcyBjaGFuZ2VkLCAxNCBpbnNlcnRpb25zKCspLCAwIGRlbGV0 aW9ucygtKQoKZGlmZiAtLWdpdCBhL21tL3Ztc2Nhbi5jIGIvbW0vdm1zY2FuLmMKaW5kZXggZGNl Mjc2Ny4uMzY4OGY0NyAxMDA2NDQKLS0tIGEvbW0vdm1zY2FuLmMKKysrIGIvbW0vdm1zY2FuLmMK QEAgLTI3Nyw2ICsyNzcsMjAgQEAgdW5zaWduZWQgbG9uZyBzaHJpbmtfc2xhYihzdHJ1Y3Qgc2hy aW5rX2NvbnRyb2wgKnNocmluaywKIAkJfQogCiAJCS8qCisJCSAqIEF2b2lkIGV4Y2Vzc2l2ZSB3 aW5kdXAgb24gZmllbHN5c3RlbSBzaHJpbmtlcnMgZHVlIHRvIGxhcmdlCisJCSAqIG51bWJlcnMg b2YgR0ZQX05PRlMgYWxsb2NhdGlvbnMgY2F1c2luZyB0aGUgc2hyaW5rZXJzIHRvCisJCSAqIHJl dHVybiAtMSBhbGwgdGhlIHRpbWUuIFRoaXMgcmVzdWx0cyBpbiBhIGxhcmdlIG5yIGJlaW5nCisJ CSAqIGJ1aWx0IHVwIHNvIHdoZW4gYSBzaHJpbmsgdGhhdCBjYW4gZG8gc29tZSB3b3JrIGNvbWVz IGFsb25nCisJCSAqIGl0IGVtcHRpZXMgdGhlIGVudGlyZSBjYWNoZSBkdWUgdG8gbnIgPj4+IG1h eF9wYXNzLiAgVGhpcyBpcworCQkgKiBiYWQgZm9yIHN1c3RhaW5pbmcgYSB3b3JraW5nIHNldCBp biBtZW1vcnkuCisJCSAqCisJCSAqIEhlbmNlIG9ubHkgYWxsb3cgbnIgdG8gZ28gbGFyZ2Ugd2hl biBhIGxhcmdlIGRlbHRhIGlzCisJCSAqIGNhbGN1bGF0ZWQuCisJCSAqLworCQlpZiAoZGVsdGEg PCBtYXhfcGFzcyAvIDQpCisJCQl0b3RhbF9zY2FuID0gbWluKHRvdGFsX3NjYW4sIG1heF9wYXNz IC8gMik7CisKKwkJLyoKIAkJICogQXZvaWQgcmlza2luZyBsb29waW5nIGZvcmV2ZXIgZHVlIHRv IHRvbyBsYXJnZSBuciB2YWx1ZToKIAkJICogbmV2ZXIgdHJ5IHRvIGZyZWUgbW9yZSB0aGFuIHR3 aWNlIHRoZSBlc3RpbWF0ZSBudW1iZXIgb2YKIAkJICogZnJlZWFibGUgZW50cmllcy4KLS0gCjEu Ny41LjEKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnhm cyBtYWlsaW5nIGxpc3QKeGZzQG9zcy5zZ2kuY29tCmh0dHA6Ly9vc3Muc2dpLmNvbS9tYWlsbWFu L2xpc3RpbmZvL3hmcwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933113Ab1FBHBx (ORCPT ); Thu, 2 Jun 2011 03:01:53 -0400 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:27352 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932960Ab1FBHBq (ORCPT ); Thu, 2 Jun 2011 03:01:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYDAAky5015LCoegWdsb2JhbABThEmhZxUBARYmJbZukGKBK4NsgQoEoCk From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com Subject: [PATCH 03/12] vmscan: reduce wind up shrinker->nr when shrinker can't do work Date: Thu, 2 Jun 2011 17:00:58 +1000 Message-Id: <1306998067-27659-4-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Chinner When a shrinker returns -1 to shrink_slab() to indicate it cannot do any work given the current memory reclaim requirements, it adds the entire total_scan count to shrinker->nr. The idea ehind this is that whenteh shrinker is next called and can do work, it will do the work of the previously aborted shrinker call as well. However, if a filesystem is doing lots of allocation with GFP_NOFS set, then we get many, many more aborts from the shrinkers than we do successful calls. The result is that shrinker->nr winds up to it's maximum permissible value (twice the current cache size) and then when the next shrinker call that can do work is issued, it has enough scan count built up to free the entire cache twice over. This manifests itself in the cache going from full to empty in a matter of seconds, even when only a small part of the cache is needed to be emptied to free sufficient memory. Under metadata intensive workloads on ext4 and XFS, I'm seeing the VFS caches increase memory consumption up to 75% of memory (no page cache pressure) over a period of 30-60s, and then the shrinker empties them down to zero in the space of 2-3s. This cycle repeats over and over again, with the shrinker completely trashing the Ń–node and dentry caches every minute or so the workload continues. This behaviour was made obvious by the shrink_slab tracepoints added earlier in the series, and made worse by the patch that corrected the concurrent accounting of shrinker->nr. To avoid this problem, stop repeated small increments of the total scan value from winding shrinker->nr up to a value that can cause the entire cache to be freed. We still need to allow it to wind up, so use the delta as the "large scan" threshold check - if the delta is more than a quarter of the entire cache size, then it is a large scan and allowed to cause lots of windup because we are clearly needing to free lots of memory. If it isn't a large scan then limit the total scan to half the size of the cache so that windup never increases to consume the whole cache. Reducing the total scan limit further does not allow enough wind-up to maintain the current levels of performance, whilst a higher threshold does not prevent the windup from freeing the entire cache under sustained workloads. Signed-off-by: Dave Chinner --- mm/vmscan.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index dce2767..3688f47 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -277,6 +277,20 @@ unsigned long shrink_slab(struct shrink_control *shrink, } /* + * Avoid excessive windup on fielsystem shrinkers due to large + * numbers of GFP_NOFS allocations causing the shrinkers to + * return -1 all the time. This results in a large nr being + * built up so when a shrink that can do some work comes along + * it empties the entire cache due to nr >>> max_pass. This is + * bad for sustaining a working set in memory. + * + * Hence only allow nr to go large when a large delta is + * calculated. + */ + if (delta < max_pass / 4) + total_scan = min(total_scan, max_pass / 2); + + /* * Avoid risking looping forever due to too large nr value: * never try to free more than twice the estimate number of * freeable entries. -- 1.7.5.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: [PATCH 03/12] vmscan: reduce wind up shrinker->nr when shrinker can't do work Date: Thu, 2 Jun 2011 17:00:58 +1000 Message-ID: <1306998067-27659-4-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com To: linux-fsdevel@vger.kernel.org Return-path: In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org From: Dave Chinner When a shrinker returns -1 to shrink_slab() to indicate it cannot do any work given the current memory reclaim requirements, it adds the entire total_scan count to shrinker->nr. The idea ehind this is that whenteh shrinker is next called and can do work, it will do the work of the previously aborted shrinker call as well. However, if a filesystem is doing lots of allocation with GFP_NOFS set, then we get many, many more aborts from the shrinkers than we do successful calls. The result is that shrinker->nr winds up to it's maximum permissible value (twice the current cache size) and then when the next shrinker call that can do work is issued, it has enough scan count built up to free the entire cache twice over. This manifests itself in the cache going from full to empty in a matter of seconds, even when only a small part of the cache is needed to be emptied to free sufficient memory. Under metadata intensive workloads on ext4 and XFS, I'm seeing the VFS caches increase memory consumption up to 75% of memory (no page cache pressure) over a period of 30-60s, and then the shrinker empties them down to zero in the space of 2-3s. This cycle repeats over and over again, with the shrinker completely trashing the =D1=96node and dentry caches every minute or so the workload continues. This behaviour was made obvious by the shrink_slab tracepoints added earlier in the series, and made worse by the patch that corrected the concurrent accounting of shrinker->nr. To avoid this problem, stop repeated small increments of the total scan value from winding shrinker->nr up to a value that can cause the entire cache to be freed. We still need to allow it to wind up, so use the delta as the "large scan" threshold check - if the delta is more than a quarter of the entire cache size, then it is a large scan and allowed to cause lots of windup because we are clearly needing to free lots of memory. If it isn't a large scan then limit the total scan to half the size of the cache so that windup never increases to consume the whole cache. Reducing the total scan limit further does not allow enough wind-up to maintain the current levels of performance, whilst a higher threshold does not prevent the windup from freeing the entire cache under sustained workloads. Signed-off-by: Dave Chinner --- mm/vmscan.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index dce2767..3688f47 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -277,6 +277,20 @@ unsigned long shrink_slab(struct shrink_control *shr= ink, } =20 /* + * Avoid excessive windup on fielsystem shrinkers due to large + * numbers of GFP_NOFS allocations causing the shrinkers to + * return -1 all the time. This results in a large nr being + * built up so when a shrink that can do some work comes along + * it empties the entire cache due to nr >>> max_pass. This is + * bad for sustaining a working set in memory. + * + * Hence only allow nr to go large when a large delta is + * calculated. + */ + if (delta < max_pass / 4) + total_scan =3D min(total_scan, max_pass / 2); + + /* * Avoid risking looping forever due to too large nr value: * never try to free more than twice the estimate number of * freeable entries. --=20 1.7.5.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter= .ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id 295DA6B007E for ; Thu, 2 Jun 2011 03:01:44 -0400 (EDT) From: Dave Chinner Subject: [PATCH 03/12] vmscan: reduce wind up shrinker->nr when shrinker can't do work Date: Thu, 2 Jun 2011 17:00:58 +1000 Message-Id: <1306998067-27659-4-git-send-email-david@fromorbit.com> In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com From: Dave Chinner When a shrinker returns -1 to shrink_slab() to indicate it cannot do any work given the current memory reclaim requirements, it adds the entire total_scan count to shrinker->nr. The idea ehind this is that whenteh shrinker is next called and can do work, it will do the work of the previously aborted shrinker call as well. However, if a filesystem is doing lots of allocation with GFP_NOFS set, then we get many, many more aborts from the shrinkers than we do successful calls. The result is that shrinker->nr winds up to it's maximum permissible value (twice the current cache size) and then when the next shrinker call that can do work is issued, it has enough scan count built up to free the entire cache twice over. This manifests itself in the cache going from full to empty in a matter of seconds, even when only a small part of the cache is needed to be emptied to free sufficient memory. Under metadata intensive workloads on ext4 and XFS, I'm seeing the VFS caches increase memory consumption up to 75% of memory (no page cache pressure) over a period of 30-60s, and then the shrinker empties them down to zero in the space of 2-3s. This cycle repeats over and over again, with the shrinker completely trashing the N?node and dentry caches every minute or so the workload continues. This behaviour was made obvious by the shrink_slab tracepoints added earlier in the series, and made worse by the patch that corrected the concurrent accounting of shrinker->nr. To avoid this problem, stop repeated small increments of the total scan value from winding shrinker->nr up to a value that can cause the entire cache to be freed. We still need to allow it to wind up, so use the delta as the "large scan" threshold check - if the delta is more than a quarter of the entire cache size, then it is a large scan and allowed to cause lots of windup because we are clearly needing to free lots of memory. If it isn't a large scan then limit the total scan to half the size of the cache so that windup never increases to consume the whole cache. Reducing the total scan limit further does not allow enough wind-up to maintain the current levels of performance, whilst a higher threshold does not prevent the windup from freeing the entire cache under sustained workloads. Signed-off-by: Dave Chinner --- mm/vmscan.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index dce2767..3688f47 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -277,6 +277,20 @@ unsigned long shrink_slab(struct shrink_control *shrink, } /* + * Avoid excessive windup on fielsystem shrinkers due to large + * numbers of GFP_NOFS allocations causing the shrinkers to + * return -1 all the time. This results in a large nr being + * built up so when a shrink that can do some work comes along + * it empties the entire cache due to nr >>> max_pass. This is + * bad for sustaining a working set in memory. + * + * Hence only allow nr to go large when a large delta is + * calculated. + */ + if (delta < max_pass / 4) + total_scan = min(total_scan, max_pass / 2); + + /* * Avoid risking looping forever due to too large nr value: * never try to free more than twice the estimate number of * freeable entries. -- 1.7.5.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org