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 A1DDEC04A6A for ; Wed, 2 Aug 2023 15:50:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CEFE2801BE; Wed, 2 Aug 2023 11:50:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05B3F2801AA; Wed, 2 Aug 2023 11:50:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E625A2801BE; Wed, 2 Aug 2023 11:50:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D422C2801AA for ; Wed, 2 Aug 2023 11:50:53 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 88B43A0721 for ; Wed, 2 Aug 2023 15:50:53 +0000 (UTC) X-FDA: 81079602786.10.4FA44A0 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf11.hostedemail.com (Postfix) with ESMTP id 50A2F40038 for ; Wed, 2 Aug 2023 15:50:49 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Ji6vEcAr; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690991450; 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:dkim-signature; bh=eqq4Vm0LVu000apc9oEBff9Oeg2w+Ug93UCmZeZYG6U=; b=HpKdJE5+n0EQODJYEZkOpzO/YXp4PHy9XeXqTYEfnwxKT/WIcJlIqGc0Jm/dovjbhmw1Kc 6cvyeZ5iSx2NCsOiSWwmhwD+XQN+kxZ9gr+XgVmQSudAe6xFPmwcucvyXrQo8VxK5Q2hwV tsndTyRRDEoB1MPfbg1ige8xbu67Wp8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690991450; a=rsa-sha256; cv=none; b=UoRnQHhp4hfnQpz5IntpaON16out1T6hkcyx3opfLtdqY0j15pWURKQh+/b7po7ywoew5M Tv/Z0ZGndJNnOLuXkBGrEz2OLWy+5VxNRzrCKkSNTq8iMMlAyomuGYbFbm7G3XYrQRSjMO x80uC6KhZbuI8GTGiTdm2nziO7CdLFM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Ji6vEcAr; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E26A3219FF; Wed, 2 Aug 2023 15:50:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1690991447; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eqq4Vm0LVu000apc9oEBff9Oeg2w+Ug93UCmZeZYG6U=; b=Ji6vEcArb9iIMblZcbVk9q9oAKbAOktwkmnsUyh8HQ6z8jeFt1Lsn+EDrlP8CSlYdOQXpb i6vARq3L+4TuFHcx1E5e4mxjpC6pjJ1546U9AF55sjMsjdGBvXIZDoOt4GxzdimCEe9O22 FOVBSOQxdxGeOAY/lyYx0W+UpR03E68= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C460A13909; Wed, 2 Aug 2023 15:50:47 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DEPqLFd7ymR7OQAAMHmgww (envelope-from ); Wed, 02 Aug 2023 15:50:47 +0000 Date: Wed, 2 Aug 2023 17:50:46 +0200 From: Michal Hocko To: Aneesh Kumar K V Cc: linux-mm@kvack.org, akpm@linux-foundation.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, npiggin@gmail.com, christophe.leroy@csgroup.eu, Oscar Salvador , David Hildenbrand , Vishal Verma Subject: Re: [PATCH v7 7/7] mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter Message-ID: References: <20230801044116.10674-1-aneesh.kumar@linux.ibm.com> <20230801044116.10674-8-aneesh.kumar@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: crddssp7szfqr94rcimcjuf4oxcwjpjp X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 50A2F40038 X-Rspam-User: X-HE-Tag: 1690991449-971783 X-HE-Meta: U2FsdGVkX1/s8MGlz+ANwKgsyoRtlBPjYPdrSeQEYdZYFAvSPBVL1UWA5jZfKXTjwerIdqfuqHj9+UhDEV6y749ZsIbjNChYrfIF2829jmlQg7oW7cERsMFF4+mAHpm4pUQl49mvd9V/U7krfm7buNoqyyIfUcs/EUDW/CGfQVPE8I6PUB5b/6CyOa6/kqVCIiKhME9ecmobgzhh2c9zxPtElzx9pPX/HP/8viUd2Q2BeRk608yOiuA1mda3GroUdCYVKPD93FXXuBoH59MLyMT4Sq0Oc36/buDAzJbIj+iU3cDqZl5vtdfD3irLqgWCJuswXC7cFxbr9ZFxHUXMyrOIzX4kuA54CRzsVf2l3E38l7GAqQ8R7psWX6fV/a/bdIG7UyvC4TpEViRywUVcVlQoQOTih1q4v789mJD61f+sKZfGdE6YvqRtXzgok/75lMTeEtaULmrC2UzQiVpFjTgRd3pxF02cGJ+J4AmPi8+D990GAns99hgVCwEGT2GO1ei4CT6XlhuSsQXmLDk2nk2G7CiwkXK34mTmJQxg2cbDQTRPEZKxAtMl/2XwxxLcmwE42wUBb8TSKPSJXrifnF8ZFYrr/5QqPRfarUAkoRDNhGeN0lir95iWZrKKGzcN0cPCeKP5JClZMKQV+xWJmB8OFgJHAb8Q0k83GN1nLgtaUf492BHSA0HQ0HIVlday0BxLbXw9S6AFgDqHOIHES07TP9s7pLW1bG662F3xEXyirDN0kXn5AGe2GtEGmwBvPhaOIZULypphPAoSceR39dbG2H79S1R0MBbd3hClEf53AXuDVZkNVI3zwbgI1L5g4qHW3tH09CBTryHeFUn4GlWGTdMl/AdlNbtJwjQ/K341XNpiEIxx8dR+xFJI4d9szQZEyEkzPRnfLlfrxnS6v8D+C6vTgrPKfJ3Jc9Rip91U8LCYC69uL1Lpe62G0A1fIJU1QH5TS1OaeEXTkEN ZwIv+8o+ JqanePB6bntuGwTGuqHKWNKztDgHPnf2mtS8m9bA9RAMVti4Y9kZjRQ6Ix+VXTkJjoZKborOBI3Wfun14lA5iwx0AYDr3IWh35TJlvdsE0VPlafx+i7XDmaB/NLEEswnOjzNv2in9wAJWzTSwAX+vB4j8s6eJ004CkMU0DYlmdj4fgXvkl6hHoqg+36gLLdFf6FO42gyTQsram/M= 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 Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote: > On 8/1/23 4:20 PM, Michal Hocko wrote: > > On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote: > >> On 8/1/23 2:28 PM, Michal Hocko wrote: > >>> On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote: > >>>> Allow updating memmap_on_memory mode after the kernel boot. Memory > >>>> hotplug done after the mode update will use the new mmemap_on_memory > >>>> value. > >>> > >>> Well, this is a user space kABI extension and as such you should spend > >>> more words about the usecase. Why we could live with this static and now > >>> need dynamic? > >>> > >> > >> This enables easy testing of memmap_on_memory feature without a kernel reboot. > > > > Testing alone is rather weak argument to be honest. > > > >> I also expect people wanting to use that when they find dax kmem memory online > >> failing because of struct page allocation failures[1]. User could reboot back with > >> memmap_on_memory=y kernel parameter. But being able to enable it via sysfs makes > >> the feature much more useful. > > > > Sure it can be useful but that holds for any feature, right. The main > > question is whether this is worth maintaing. The current implementation > > seems rather trivial which is an argument to have it but are there any > > risks long term? Have you evaluated a potential long term maintenance > > cost? There is no easy way to go back and disable it later on without > > breaking some userspace. > > > > All that should be in the changelog! > > I updated it as below. > > mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter > > Allow updating memmap_on_memory mode after the kernel boot. Memory > hotplug done after the mode update will use the new mmemap_on_memory > value. > > It is now possible to test the memmap_on_memory feature easily without > the need for a kernel reboot. Additionally, for those encountering > struct page allocation failures while using dax kmem memory online, this > feature may prove useful. Instead of rebooting with the > memmap_on_memory=y kernel parameter, users can now enable it via sysfs, > which greatly enhances its usefulness. I do not really see a solid argument why rebooting is really a problem TBH. Also is the global policy knob really the right fit for existing hotplug usecases? In other words, if we really want to make memmap_on_memory more flexible would it make more sense to have it per memory block property instead (the global knob being the default if admin doesn't specify it differently). -- Michal Hocko SUSE Labs