From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by kanga.kvack.org (Postfix) with ESMTP id 8FDF76B00D8 for ; Mon, 5 May 2014 20:29:34 -0400 (EDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so3631006pab.10 for ; Mon, 05 May 2014 17:29:34 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [2607:f8b0:400e:c03::233]) by mx.google.com with ESMTPS id yd10si10218840pab.2.2014.05.05.17.29.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 17:29:33 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so3630997pab.10 for ; Mon, 05 May 2014 17:29:33 -0700 (PDT) Date: Mon, 5 May 2014 17:29:31 -0700 (PDT) From: David Rientjes Subject: Re: [patch v2 3/4] mm, compaction: add per-zone migration pfn cache for async compaction In-Reply-To: <53679F16.8020007@suse.cz> Message-ID: References: <53675B3A.5090607@suse.cz> <53679F16.8020007@suse.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: Andrew Morton , Mel Gorman , Rik van Riel , Joonsoo Kim , Greg Thelen , Hugh Dickins , linux-kernel@vger.kernel.org, linux-mm@kvack.org On Mon, 5 May 2014, Vlastimil Babka wrote: > I see, although I would still welcome some numbers to back such change. It's pretty difficult to capture numbers for this in real-world scenarios since it happens rarely (and when it happens, it's very significant latency) and without an instrumented kernel that will determine how many pageblocks have been skipped. I could create a synthetic example of it in the kernel and get numbers for a worst-case scenario with a 64GB zone if you'd like, I'm not sure how representative it will be. > What I still don't like is the removal of the intent of commit 50b5b094e6. You > now again call set_pageblock_skip() unconditionally, thus also on pageblocks > that async compaction skipped due to being non-MOVABLE. The sync compaction > will thus ignore them. > I'm not following you, with this patch there are two cached pfns for the migration scanner: one is used for sync and one is used for async. When cc->sync == true, both cached pfns are updated (async is not going to succeed for a pageblock when sync failed for that pageblock); when cc->sync == false, the async cached pfn is updated only and we pick up again where we left off for subsequent async compactions. Sync compaction will still begin where it last left off and consider these non-MOVABLE pageblocks. -- 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/ . Don't email: email@kvack.org