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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 3108EFA372C for ; Thu, 7 Nov 2019 00:52:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EA8D62084D for ; Thu, 7 Nov 2019 00:52:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA8D62084D 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 8375D6B0003; Wed, 6 Nov 2019 19:52:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E80F6B0006; Wed, 6 Nov 2019 19:52:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AFB66B0007; Wed, 6 Nov 2019 19:52:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id 51D9A6B0003 for ; Wed, 6 Nov 2019 19:52:10 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 0E2FD45BB for ; Thu, 7 Nov 2019 00:52:10 +0000 (UTC) X-FDA: 76127654820.05.aunt19_8748cd355bc1b X-HE-Tag: aunt19_8748cd355bc1b X-Filterd-Recvd-Size: 4090 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 00:52:09 +0000 (UTC) Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5B9E8C049D62 for ; Thu, 7 Nov 2019 00:52:08 +0000 (UTC) Received: by mail-wr1-f72.google.com with SMTP id f8so149185wrq.6 for ; Wed, 06 Nov 2019 16:52:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=9/dkT2xyWGejJe5M/djTbhLlPDnSY4puajnKSb/UDbo=; b=E7jZN591pfjqKTBOGHHy/GBL6p284YLz9sOTipeQBFxN9Pm9+OExij0+V6irAJOvHI WcNeuH66fXN8Kl8bunc3OTi8TPONGRz73QOrECeyFkqjaUxkC2I+Ro+/iewDNZq6wr8D If1yRGKY9UXtj7TjQsLMUyjuh2zmrLiQtHioOlHPuhqLTa5NZ7/IBpB1kQjKhipAp6YN F9HAeSMWXgEc6zjZCFBJAtQ96kgd1PcbbYCWCvbuZ0P43EIHZ9Sl7Bce7GpCFgJ6ox4/ Zu07fyV+6b2iEmhU3YDPNFdqGu6JLMQMTKCqedfGPj5uLwcYrapuDK14+ePBT+FuZtJ/ 5q7A== X-Gm-Message-State: APjAAAV6u3bBJBu9I8tm9V/3qnKUWJ786BDLPZNxdhVKAfnjpCtB0gD2 qfT7o6pp5HTlKc7lV3tjsBvTLrKYXs/A867PjRDr8bgIRhwKzW31AsZgxdMcEQdkc1nKpn7lIbq 7b6ufKHQXIEQ= X-Received: by 2002:a05:600c:3cc:: with SMTP id z12mr311647wmd.151.1573087927118; Wed, 06 Nov 2019 16:52:07 -0800 (PST) X-Google-Smtp-Source: APXvYqysoH5uU9L7vAXP0trdySBMR2OYAWyCqaA7HJMIwPVKsajHNVq6VIEvoVVDjY38pRrPhR8uYQ== X-Received: by 2002:a05:600c:3cc:: with SMTP id z12mr311617wmd.151.1573087926897; Wed, 06 Nov 2019 16:52:06 -0800 (PST) Received: from [192.168.3.122] (p5B0C646D.dip0.t-ipconnect.de. [91.12.100.109]) by smtp.gmail.com with ESMTPSA id z13sm525412wrm.64.2019.11.06.16.52.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2019 16:52:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Hildenbrand Mime-Version: 1.0 (1.0) Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree Date: Thu, 7 Nov 2019 01:52:05 +0100 Message-Id: <92C323F0-41BE-4988-8C39-1513FAC40458@redhat.com> References: <95a78ac2-73bf-2985-9769-e269e8d13d68@intel.com> Cc: Alexander Duyck , Michal Hocko , akpm@linux-foundation.org, aarcange@redhat.com, dan.j.williams@intel.com, konrad.wilk@oracle.com, lcapitulino@redhat.com, mgorman@techsingularity.net, mm-commits@vger.kernel.org, mst@redhat.com, osalvador@suse.de, pagupta@redhat.com, pbonzini@redhat.com, riel@surriel.com, vbabka@suse.cz, wei.w.wang@intel.com, willy@infradead.org, yang.zhang.wz@gmail.com, linux-mm@kvack.org In-Reply-To: <95a78ac2-73bf-2985-9769-e269e8d13d68@intel.com> To: Dave Hansen X-Mailer: iPhone Mail (17A878) 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: > Am 07.11.2019 um 01:20 schrieb Dave Hansen : >=20 > =EF=BB=BFOn 11/6/19 3:33 PM, David Hildenbrand wrote: >> We want do discuss *design* and *architecture* here, not >> *implementation details*. >=20 > Could folks remind me what they see as the high-level design delta > between these two approaches? >=20 > It seems to me like Alex's approach tries to minimize new metadata, but > imposes some rules on the internals of the allocator. Nitesh's is more > disconnected from the allocator, but has the increased complexity of > managing some new disjoint metadata. >=20 > Right? Very right AFAIKS. It=E2=80=99s a matter of where to store new metadata and h= ow to stop the buddy from reusing pages that are currently getting reported.= The latter does not spill virt specific optimization stuff into the core bud= dy, which is why that information has to be tracked differently.=