From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7889C49EA5 for ; Fri, 25 Jun 2021 02:21:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF279613C1 for ; Fri, 25 Jun 2021 02:21:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233032AbhFYCXP (ORCPT ); Thu, 24 Jun 2021 22:23:15 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:39979 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232942AbhFYCXO (ORCPT ); Thu, 24 Jun 2021 22:23:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624587654; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=FUVevOBJKOHME2+koqTYq7Ae8rIdtCaF17FidUos6Rw=; b=asESPVWgUXAUH5eX3scw1gS4VhVVli9ur8g1OkH92Fj1Ne0Bit9uejWzOfhf88/6xRreHO FVqhYM6Gn6uLlpSLRUrEvBuUhT1YrBDHR7rebPUGprbkBq6GvS5USpBLTW6thG+TF4oRjc P5cggIAFLuV2HyIVqFJYU6frJWcraoE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-142-kWeybz1jPm2YDFcPcGVJpg-1; Thu, 24 Jun 2021 22:20:52 -0400 X-MC-Unique: kWeybz1jPm2YDFcPcGVJpg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BCA5E18414A4; Fri, 25 Jun 2021 02:20:50 +0000 (UTC) Received: from gshan.redhat.com (vpn2-54-70.bne.redhat.com [10.64.54.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id 18CB15C1A3; Fri, 25 Jun 2021 02:20:40 +0000 (UTC) From: Gavin Shan To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, alexander.duyck@gmail.com, david@redhat.com, mst@redhat.com, akpm@linux-foundation.org, anshuman.khandual@arm.com, catalin.marinas@arm.com, will@kernel.org, shan.gavin@gmail.com Subject: [PATCH v5 0/4] mm/page_reporting: Make page reporting work on arm64 with 64KB page size Date: Fri, 25 Jun 2021 12:21:46 +0800 Message-Id: <20210625042150.46964-1-gshan@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The page reporting threshold is currently equal to @pageblock_order, which is 13 and 512MB on arm64 with 64KB base page size selected. The page reporting won't be triggered if the freeing page can't come up with a free area like that huge. The condition is hard to be met, especially when the system memory becomes fragmented. This series intends to solve the issue by having page reporting threshold as 5 (2MB) on arm64 with 64KB base page size. The patches are organized as: PATCH[1/4] Fix some coding style in __page_reporting_request(). PATCH[2/4] Represents page reporting order with variable so that it can be exported as module parameter. PATCH[3/4] Allows the device driver (e.g. virtio_balloon) to specify the page reporting order when the device info is registered. PATCH[4/4] Specifies the page reporting order to 5, corresponding to 2MB in size on ARM64 when 64KB base page size is used. Changelog ========= v5: * Restore @page_reporting_order to @pageblock_order when device is registered in PATCH[2/4] to keep "git bisect" friendly at least. (Alex) v4: * Set @page_reporting_order to MAX_ORDER. Its value is specified by the driver or falls back to @pageblock_order when page reporting device is registered. (Alex) * Include "module.h" in page_reporting.c (Andrew) v3: * Avoid overhead introduced by function all (Alex) * Export page reporting order as module parameter (Gavin) v2: * Rewrite the patches as Alex suggested (Alex) Gavin Shan (4): mm/page_reporting: Fix code style in __page_reporting_request() mm/page_reporting: Export reporting order as module parameter mm/page_reporting: Allow driver to specify reporting virtio_balloon: Specify page reporting order if needed .../admin-guide/kernel-parameters.txt | 6 +++++ drivers/virtio/virtio_balloon.c | 17 ++++++++++++++ include/linux/page_reporting.h | 3 +++ mm/page_reporting.c | 22 +++++++++++++++---- mm/page_reporting.h | 5 ++--- 5 files changed, 46 insertions(+), 7 deletions(-) -- 2.23.0