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=-7.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 77904C48BE5 for ; Mon, 21 Jun 2021 05:51:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1438E6113C for ; Mon, 21 Jun 2021 05:51:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1438E6113C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 167B96B006E; Mon, 21 Jun 2021 01:51:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 119316B0072; Mon, 21 Jun 2021 01:51:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAD926B0074; Mon, 21 Jun 2021 01:51:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id B7CF06B006E for ; Mon, 21 Jun 2021 01:51:42 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 38B3D1120F for ; Mon, 21 Jun 2021 05:51:42 +0000 (UTC) X-FDA: 78276659244.28.5F75E36 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id C5FBC600056A for ; Mon, 21 Jun 2021 05:51:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624254701; h=from:from:reply-to: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: in-reply-to:in-reply-to:references:references; bh=x4pB8j6tDZRW0gLAsi2832dbbAuey5XcjoKSFTOd6GI=; b=TW3rmwVsGzW92XTdsQM7fFymzg/URlEwxCxfi1Vrb0tGMFFuizkprc7zkwl+oef2zrb+mv I0ZfZEBD9ze9h14OFRSfjdogm89vL+xb4QiVGvHyBQfA2foY/r5RxqAIYleyauw4fZWN3N Q1aH7y/Uw9oMWnQSJf3iS8L/Y97xDkE= 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-332-NfR_JVlMN6m7pwdk431LCw-1; Mon, 21 Jun 2021 01:51:38 -0400 X-MC-Unique: NfR_JVlMN6m7pwdk431LCw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6707B18414A0; Mon, 21 Jun 2021 05:51:37 +0000 (UTC) Received: from [10.64.54.84] (vpn2-54-84.bne.redhat.com [10.64.54.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AC32C60861; Mon, 21 Jun 2021 05:51:30 +0000 (UTC) Reply-To: Gavin Shan Subject: Re: [RFC PATCH] mm/page_reporting: Adjust threshold according to MAX_ORDER To: Alexander Duyck Cc: David Hildenbrand , linux-mm , LKML , Andrew Morton , shan.gavin@gmail.com, Anshuman Khandual References: <20210601033319.100737-1-gshan@redhat.com> <76516781-6a70-f2b0-f3e3-da999c84350f@redhat.com> <0c0eb8c8-463d-d6f1-3cec-bbc0af0a229c@redhat.com> <63c06446-3b10-762c-3a29-464854b74e08@redhat.com> From: Gavin Shan Message-ID: <5a74f8ed-8579-290b-758f-faa24d2afa70@redhat.com> Date: Mon, 21 Jun 2021 17:52:32 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TW3rmwVs; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf25.hostedemail.com: domain of gshan@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=gshan@redhat.com X-Rspamd-Server: rspam02 X-Stat-Signature: atbgj96djt19wr4abi175mkpynw9oddk X-Rspamd-Queue-Id: C5FBC600056A X-HE-Tag: 1624254701-786305 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/17/21 12:15 AM, Alexander Duyck wrote: > On Wed, Jun 16, 2021 at 12:10 AM Gavin Shan wrote: >> On 6/15/21 12:26 PM, Alexander Duyck wrote: >>> On Mon, Jun 14, 2021 at 4:03 AM David Hildenbrand wrote: >>>> On 11.06.21 09:44, Gavin Shan wrote: >>>>> On 6/1/21 6:01 PM, David Hildenbrand wrote: >>>>>> On 01.06.21 05:33, Gavin Shan wrote: [...] >>> >>> Yes, generally reporting pages comes at a fairly high cost so it is >>> important to find the right trade-off between the size of the page and >>> the size of the batch of pages being reported. If the size of the >>> pages is reduced it maybe important to increase the batch size in >>> order to avoid paying too much in the way of overhead. >>> >>> The other main reason for holding to pageblock_order on x86 is to >>> avoid THP splitting. Anything smaller than pageblock_order will >>> trigger THP splitting which will significantly hurt the performance of >>> the VM in general as it forces it down to order 0 pages. >>> >> >> Alex, Thanks for your reply and sorry for taking your time to this >> discussion. >> >> Could you please confirm it's PAGE_REPORTING_CAPACITY or the budget >> used in page_reporting_cycle() when you're talking about "batch"? > > Yes, when I refer to batch it is how many pages we are processing in a > single call. That is limited by PAGE_REPORTING_CAPACITY. > Alex, It seems the batch mechanism is to avoid heavy contention on zone's lock if I'm correct? The current design is to report all pages in the corresponding free list within 17 calls to page_reporting_cycle(). Could you please explain why 17 was chosen? :) budget = DIV_ROUND_UP(area->nr_free, PAGE_REPORTING_CAPACITY * 16); It's related to the magic number ("16"). With the threshold is decreased, for example from 512MB to 2MB on arm64 with 64KB base page size, more page reporting activities will be introduced. From this regard, it's reasonable to increase the magic number as well, so that more calls to page_reporting_cycle() to avoid the contention to zone's lock. If you agree, I will come up with something, similar to what we do for the threshold. However, I'm not sure if 64 is reasonable cycles to have for this particular case. in arch/arm64/include/asm/page.h #ifdef CONFIG_ARM64_64K_PAGES #define PAGE_REPORTING_ORDER 5 #define PAGE_REPORTING_CYCLES 64 #endif in mm/page_reporting.h #ifndef PAGE_REPORTING_CYCLES #define PAGE_REPORTING_CYCLES 16 #endif in mm/page_reporting.c::page_reporting_cycle() budget = DIV_ROUND_UP(area->nr_free, PAGE_REPORTING_CAPACITY * PAGE_REPORTING_CYCLES); Thanks, Gavin