Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <43c610f9-8671-519c-108f-9996e219c249@intel.com>
Date:   Tue, 9 Aug 2022 22:58:18 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: [RFC PATCH 0/4] x86/mm/cpa: merge small mappings whenever
 possible
Content-Language: en-US
To:     "Kirill A. Shutemov" <kirill@shutemov.name>
CC:     Dave Hansen <dave.hansen@intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        Song Liu <song@kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-mm@kvack.org>
References: <20220808145649.2261258-1-aaron.lu@intel.com>
 <20220809100408.rm6ofiewtty6rvcl@box>
From:   Aaron Lu <aaron.lu@intel.com>
In-Reply-To: <20220809100408.rm6ofiewtty6rvcl@box>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ci8wakdNY0ZrQm1rKzFCaC9PNVhoUXNCWGdtLzBFcUxMZEx5b2tSYlR6eFBF?=
 =?utf-8?B?WWlsUnhaYm1vVzFtL2ZSYmFLaUVybVJBQm9lbC9rckZpVEU0Y0RkZllXMmlD?=
 =?utf-8?B?UGlCT1lyS1EyZnVlUWIxb0RCdTFTd2VlcFZLdHVQZXdhNjVZbFFNcElYTkFi?=
 =?utf-8?B?OHBBbTM0WEY0SUIwNTR3clYxMGFVTWJhbEdZRVU0UWlrTmFyTDc3Zm5mZEx4?=
 =?utf-8?B?NTFLRnVDMHdVTHg1NEtPeGRSY092R240OGEybVZkYjRJS3BVNTZJa2pzL0s5?=
 =?utf-8?B?dmJOdWVkUUkzNFVWYkVpN2VBU1k3L1gvKy9PVXhCNFIyZW5IeEhjTm95STV0?=
 =?utf-8?B?NzJXdi93azBla2JUdlllNjNWRWpjSGthSFltMTNidFBKY3ZTcDZ3VENLdm9r?=
 =?utf-8?B?MmhZaElmQ2Y3VVJDSHN2RmRuaUd4Uy9PSVBqWDJMdTNwaFB3Zi9iWWU3Smlj?=
 =?utf-8?B?cGRRYVgvOStDME1ReUk5UkhGZHBCK211eHduZDN4c3RtVlVKa1FodTJVR3Rv?=
 =?utf-8?B?QytiaXBldXVlZU4zL2Z2VTd0WUxpWFQwUHVWRCtnSlIvYmZPVmxIUUdpb0d4?=
 =?utf-8?B?N21CZXdNMCtCUWtXUXh0TUxIRm5XcEtmOFowSDV0VmtLM1liZTN4eUc2VzlC?=
 =?utf-8?B?QW9QSElxNGI2eU9LNStQUDNuNFpkR1EyYzFucUIrRlNVc2JHMHRtelpHRS9I?=
 =?utf-8?B?Q2JmSjhiNDlxV0V2Y2s0U2xjS0dPd012b1FIVHg5VEN6SlA1OFhzWHdlb0NT?=
 =?utf-8?B?RG5TeHJoclVFdWIzc2pDM2lLaHpoUXV4MHMzSGdBTHIxLzhjYnRHNVJSaUFo?=
 =?utf-8?B?YWVESi9OVjlVcjV2cDA2azk0OGtta2xlcFp1b3g2d3RuVEg4cmgyS0M3ZDZy?=
 =?utf-8?B?dTBKc3IyMEcwRWx2NE56anMyZ3FzMVAvZTZlTFUrK0pkbXZEL1pvS1JnT2w2?=
 =?utf-8?B?ejUzRHdlN1NvRURFN2xTMy9lS2Raa29FWURtZy9OejJlR1BWVFV1WVdEYTR6?=
 =?utf-8?B?TVJoc1JUYXNtZHczQTh4aVIvckF3TEREdGtpaDdzSTFKL2VXYis4L3llaWhp?=
 =?utf-8?B?RG9oMkFwRFZTVEhhckxsNW9MNDEyYjhqcW5PVmtPMFVqTEJ4dzg0RFgwWnho?=
 =?utf-8?B?R2wvbHhWVUFRbEZPM3pnRHBXcGNLQkRzMTBFM0o4bHZkK0taWXBQa2JoTElk?=
 =?utf-8?B?QlVuaDZkd1pqZkMxQjlLUXBobGk3dEV1VEdibVMweDVhcTYxd015QTVJWkMr?=
 =?utf-8?B?T3VIVXNoejFCdyt5cXR2SDFiRDdZTmZEQ3Q0QWlrdkRTM2dZNkxCaEFoZE5W?=
 =?utf-8?B?SExoUktpYkVJUVBJeXBPV2d6eFllN3czTXYwM3hIWk5jNTEyTm5pbi9wTG9x?=
 =?utf-8?B?eFAwWnVDSTN4Z2pkTksrWW9mZUVXSnQwVXpVamw1T2xHZVFqaDQxa0t0TTJk?=
 =?utf-8?B?bzlNL2dubzBlS29sbGFwS3Y3U004VmtLS3ZGYWttdnhkR3NrYm1KVTJKQ2ww?=
 =?utf-8?B?WWY3TktyeS8raFBKNWpTVENnb2MyYUZnZ1VwQ3Y5a25oNkhKSkFZUEY2SG5w?=
 =?utf-8?B?anVuUnFxYnExVFVZNDFxL0k3aEM3U3lqblp2Tllxd2pjWGJ1amNiTFk2WFJs?=
 =?utf-8?B?UEZWTkttUTdrWmIzTEoxQnFQS0xSSVQ4R0pQT3REVDErNXQ2NmIzZzl5UFds?=
 =?utf-8?B?akw1MG9YOGFNekRxc0Zqc00vVE8wZkxyZ2liUHdBTVdtb0FZaE40QW5ncmcz?=
 =?utf-8?B?aEpHU0dzbjEwcStZUmVXS0NyWVRjVzdEWEV6bHY5Snc5SXZnNWlyMVVtOWYy?=
 =?utf-8?B?ckFlRjdrZGNJc0VDU1pKdmFwVVhRNmxiNjJWajNLcWRKOVRJdUd4am5nVERF?=
 =?utf-8?B?SVdFbndWaG15N1NlK1FNdTV3R2g5R2o0NFF5SGNxS3ZJUXJ6RUFxQ2FIakpo?=
 =?utf-8?B?ZUVaaVF3TjN5RWdncFhJcFdmMEszS1BsY0UyQktQc0FxdEFlMXZnVnllUHAz?=
 =?utf-8?B?Ym45UGJVemxJNzVGVDEvbnI1ZG1ub1dPbG1HQklaSDRXODdwZmR4OHdQenZl?=
 =?utf-8?B?ZXpYSitLc1hud09BM2c0a1lCS1RUY1ZERGhvVlM4UUpSVkplVmpRbEpwa0Zs?=
 =?utf-8?Q?EP/QRSDxLrOuFsPgs6c9o5u2A?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 53e709e2-caab-49c7-f2c6-08da7a179dd1
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3062.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Aug 2022 14:58:28.0089
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: oOF92tlVjEITuChaI801MBI8VAaB7rfim4NTrphyux6oZElG5dwhRjkMKjynpH3oyHq+pVC5CDY9dLMlInhnbA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2551
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Kirill,

Thanks a lot for the feedback.

On 8/9/2022 6:04 PM, Kirill A. Shutemov wrote:
> 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.
>

Do you happen to remember the workload name? I can try running it.

> Have you done any performance evaluation?
> 

Not yet, I was mostly concentrating on correctness. In addition to the
graphics workload, do you have anything else in mind that may be
sensitive to such a change?

I think maybe I can run patch4's mode0 test with and without this merge
functionality and see how performance would change since mode0 is
essentially doing various set_memory_X() calls on different cpus
simultaneously which can trigger a lot of splits and merges. Sounds good?

> 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.
> 

Appreciate your suggestion.

> Also I don't see you handling set_memory_4k(). Huh?
>

Ah Right, I missed that. Currently set_memory_4k() is not specially
handled and can be mistakenly merged. Will fix this in later versions.

> [1] https://lore.kernel.org/lkml/20200416213229.19174-1-kirill.shutemov@linux.intel.com/
> 

Thanks!