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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C59AC19F2D for ; Tue, 9 Aug 2022 10:32:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFBAA8E0001; Tue, 9 Aug 2022 06:32:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E84366B0072; Tue, 9 Aug 2022 06:32:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D242D8E0001; Tue, 9 Aug 2022 06:32:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BF8256B0071 for ; Tue, 9 Aug 2022 06:32:48 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8B6DA140DB9 for ; Tue, 9 Aug 2022 10:32:48 +0000 (UTC) X-FDA: 79779690816.23.87F6A3F Received: from box.shutemov.name (unknown [86.57.175.117]) by imf09.hostedemail.com (Postfix) with ESMTP id 10E4A140180 for ; Tue, 9 Aug 2022 10:32:47 +0000 (UTC) Received: by box.shutemov.name (Postfix, from userid 1000) id 99A71103886; Tue, 9 Aug 2022 13:04:08 +0300 (+03) Date: Tue, 9 Aug 2022 13:04:08 +0300 From: "Kirill A. Shutemov" To: Aaron Lu Cc: Dave Hansen , Rick Edgecombe , Song Liu , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 0/4] x86/mm/cpa: merge small mappings whenever possible Message-ID: <20220809100408.rm6ofiewtty6rvcl@box> References: <20220808145649.2261258-1-aaron.lu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220808145649.2261258-1-aaron.lu@intel.com> ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=none (imf09.hostedemail.com: domain of kas@box.shutemov.name has no SPF policy when checking 86.57.175.117) smtp.mailfrom=kas@box.shutemov.name; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660041168; a=rsa-sha256; cv=none; b=yELdoFgPk1ijRnwW7V8JYfDWRkxZm5kMO1edNXQyG361HObmAM2zge2YNQE3OnDXlXw9Y8 qEjz3fi+Ry8joa4C6rPk4OCkm82VTgCi8jcmzjCidqGvcHoZ8Fz/38tqj9oKRcmzf3j5ZH Ac34tXplU3+MRjcrtaltawz4kd2LLJ4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660041168; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=FQT9IUq8+s7gc16GCu/+xmGQfBW6WUkwX7YHDplGBdI=; b=XHVCf6IsoiE3CnhFnIruvVQttODazS2fi4MjZ02V9I4m87ZrhSBOL5sigBb1AgzKR8LjtV 1MM1mQ2Xvyzmq8C9lMbaNHIRYnPtIlEo9fIkvmJkzn9V1VuB5sxxOUgIufDkHTefmWIoXX KzSZnA+Kj7dUpYMibmXod6nPlEOvyCU= X-Stat-Signature: 4mpcj9nxhtd5iwqwmcdz8hzcg98f7u5r X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 10E4A140180 Authentication-Results: imf09.hostedemail.com; dkim=none; spf=none (imf09.hostedemail.com: domain of kas@box.shutemov.name has no SPF policy when checking 86.57.175.117) smtp.mailfrom=kas@box.shutemov.name; dmarc=none X-HE-Tag: 1660041167-914799 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 Mon, Aug 08, 2022 at 10:56:45PM +0800, Aaron Lu wrote: > This is an early RFC. While all reviews are welcome, reviewing this code > now will be a waste of time for the x86 subsystem maintainers. I would, > however, appreciate a preliminary review from the folks on the to and cc > list. I'm posting it to the list in case anyone else is interested in > seeing this early version. Last time[1] I tried to merge pages back in direct mapping it lead to substantial performance regression for some workloads. I cannot find the report right now, but I remember it was something graphics related. Have you done any performance evaluation? My take away was that the merge has to be batched. Like log where changes to direct mapping happens and come back to then and merge when the number of changes cross some limit. Also I don't see you handling set_memory_4k(). Huh? [1] https://lore.kernel.org/lkml/20200416213229.19174-1-kirill.shutemov@linux.intel.com/ -- Kiryl Shutsemau / Kirill A. Shutemov