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 CFFAAC04A94 for ; Mon, 7 Aug 2023 08:20:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB18B6B0072; Mon, 7 Aug 2023 04:20:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A60AD6B0074; Mon, 7 Aug 2023 04:20:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92A218D0001; Mon, 7 Aug 2023 04:20:30 -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 7F9C06B0072 for ; Mon, 7 Aug 2023 04:20:30 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3D6F01C969F for ; Mon, 7 Aug 2023 08:20:30 +0000 (UTC) X-FDA: 81096611820.02.7315D82 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf12.hostedemail.com (Postfix) with ESMTP id 3210140010 for ; Mon, 7 Aug 2023 08:20:27 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=TpcC5MgY; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691396428; 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=dHv+Q+zckl8kRXv8jZYiaBCAeHh0V9XrS6OghMZOl/8=; b=OKeuPyEiZy2L0M0cuMfNlYwwR5lUkhgk6h78Zydo5uGqZS8s7ZyAbPbqJ7efrG1v9zwH3p Ra9EIdeZjba+E86/s6JOILfwC5uozecTOGY7vlXqGRtYIgJ4XQMQ/lg94nWPnYq8xKFTAR +fRl8O76hHyof+uv6gtlGEEouiJ8UHI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=TpcC5MgY; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691396428; a=rsa-sha256; cv=none; b=JxrAlVO6WjbNncrF2cOvJoIpvn+4GhTUHkF+NHApCkdipH8goeK8Eq+f3Wb2mFqPax+BLR WO9znjXwrdDfze4TPnyznC3kGC4owETDEUEGCOI9SXMz6RGus4RYRGg6yZL2y2dRjMH5lr zbpwvszB8K/H05EPFvNjQv03V3cLWVE= 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-out2.suse.de (Postfix) with ESMTPS id 7687D1F460; Mon, 7 Aug 2023 08:20:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1691396426; 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=dHv+Q+zckl8kRXv8jZYiaBCAeHh0V9XrS6OghMZOl/8=; b=TpcC5MgYdb1YFBzo2cyT8b5I1+d31p+KNyDG3zYN3icX+h+/4/gQIVH/F1sOnx9Sym58YE dwdBmjl6C9k3yBN8c22mxXQcxzPvejbKejsk0c3vvOvO0cvueOPk8tdiJK/B4gRmM9mRSx PhF4yNPKpNkIoJbjJoXyh76vUMq0U1g= 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 2F7F513487; Mon, 7 Aug 2023 08:20:26 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ZFQdCUqp0GTSfgAAMHmgww (envelope-from ); Mon, 07 Aug 2023 08:20:26 +0000 Date: Mon, 7 Aug 2023 10:20:25 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Sebastian Andrzej Siewior , Andrew Morton , Petr Mladek , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Luis Claudio R. Goncalves" , Boqun Feng , Ingo Molnar , John Ogness , Mel Gorman , Peter Zijlstra , Thomas Gleixner , Waiman Long , Will Deacon Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Message-ID: References: <20230626081254.XmorFrhs@linutronix.de> <20230727151029.e_M9bi8N@linutronix.de> <649fa1a7-4efd-8cc7-92c7-ac7944adc283@I-love.SAKURA.ne.jp> <60d4dc52-9281-9266-4294-b514bd09e6e8@I-love.SAKURA.ne.jp> <2505f6d3-5a10-49e7-960f-12c31a62a366@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2505f6d3-5a10-49e7-960f-12c31a62a366@I-love.SAKURA.ne.jp> X-Rspamd-Queue-Id: 3210140010 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 5xycezsf73mqhu8oyigz576yfq9bsp16 X-HE-Tag: 1691396427-913886 X-HE-Meta: U2FsdGVkX1/mHd6kiRsE18NhdApW55H8WA1p3Gyt2FHJ/6JxPVynciafaFhs0iwyGNKN0UUHdp1lDQtv8bjKJ0JMehL8WNoojYqzWLnOfwE2WM1xwt6tHDOECpmtKT6mnS9kUY6ZV4LxxpMwmc6DEgxOH8Hi9Inlw96OLUcQW5Cu9HIVMr3tQ/2SiUG4EncehT8nSO9Qf2AKw9wyRPFoSRvT4LYQKVwKGAfLZ1gIzMRR2xXgjLzKmhIu+rXJsCwAHVK1NslhPGv+3NVBYdUsp63ClWFBGBtSS6cbZk9LFGbS0bVwO+MYTTm44TsxcEkV9hKMUZkSInFqYj42DJ8DUAfRhcFDs/5iOG81Gx0OFAv8KWy9gPmb8l4smIs3EzZqQovWuinawK4BNazLp3H2Z3wmrRTGthXtnh+IMZ9Aiv9Zs4WOT5ktfKsBiuAouOUSi/Z4RYTjiUJ8KDMV3Ef7zb0/YGrt2XafQL3yJuLWgB/0TqZlnehXXQ+EoUgAFrnVVgI/bcGGtCMnHFwh5fjsOr3RuCKv5nyNJogg7EDl2azEjFBfqGO2559CgO1kw3p3r0BfhUkHxXA3SDYh3RV6Bh2x8pfL9u+qVuHo/4HKmNDCoY8iNahyRnneoMVcRyUQowbM0zu6ZhFK59n0fDqAvq0DEWl6KhtHNy7FkYOZ0Fw0vPf/HUsuY8qwgexPgdLYwMUxnA/JdH5yX5tNuxqscCfXHsn+W3kDrMfkq7AM/paaQ01ACXSxOEH7uS4PxezGAFM6lSlr1hpKt2wHP+n5W4oKVk5Z8u86Y0HhRuLhJ0X6l5RsKXrIjCnlbXYlFKepEtovQembRm9ACppm3LE2su7ZEd1YekKBRsYvAKd74MRjcAd8gndedTYgygrTtKPXSUxxGEAT6qwxvsTiMVHXX6LicW164ZhgTAjkyEMZUvDSLmFMpRtw3NG7coL2zFNEzsFkVXhyjwNm3GRLb12 yET7Njxc ZJMRfa1G8O2x9GGkdKBr77Ygg7ly9X+l5h+JwO6m5uIgpCOGnqhiSOras30eaIl+t5n39m2th/rcE2wbO3OZrV6fwz/6PEh/LxsVYMBNnP887yvDQ3+pWdk8PU+H/9eVzkc90lU0QvVekf8O1qnLQy7qqJNcC2omrBiE6Qs+TfxUuIjRYSZnjHUHevVaOBzfRzM3sG3FXJk40Y03EtiqJBx10cT6GUAP5aDaiXTpQ2NaLUWOWjKxu7ou/R0pfkBMRXdnUJs6zlb8C01tDf46vkF8wpEjQNNm88b7utx8smovzaoaYfFrxKlXjxwDUEN50ki9CwnjzEvsmqAI= 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 Fri 04-08-23 22:27:22, Tetsuo Handa wrote: > On 2023/08/03 23:49, Michal Hocko wrote: > > On Thu 03-08-23 22:18:10, Tetsuo Handa wrote: > >> On 2023/07/31 23:25, Michal Hocko wrote: > >>> On Sat 29-07-23 20:05:43, Tetsuo Handa wrote: > >>>> On 2023/07/29 14:31, Tetsuo Handa wrote: > >>>>> On 2023/07/28 0:10, Sebastian Andrzej Siewior wrote: > >>>>>> On 2023-06-28 21:14:16 [+0900], Tetsuo Handa wrote: > >>>>>>>> Anyway, please do not do this change only because of printk(). > >>>>>>>> IMHO, the current ordering is more logical and the printk() problem > >>>>>>>> should be solved another way. > >>>>>>> > >>>>>>> Then, since [PATCH 1/2] cannot be applied, [PATCH 2/2] is automatically > >>>>>>> rejected. > >>>>>> > >>>>>> My understanding is that this patch gets applied and your objection will > >>>>>> be noted. > >>>>> > >>>>> My preference is that zonelist_update_seq is not checked by !__GFP_DIRECT_RECLAIM > >>>>> allocations, which is a low-hanging fruit towards GFP_LOCKLESS mentioned at > >>>>> https://lkml.kernel.org/r/ZG3+l4qcCWTPtSMD@dhcp22.suse.cz and > >>>>> https://lkml.kernel.org/r/ZJWWpGZMJIADQvRS@dhcp22.suse.cz . > >>>>> > >>>>> Maybe we can defer checking zonelist_update_seq till retry check like below, > >>>>> for this is really an infrequent event. > >>>>> > >>>> > >>>> An updated version with comments added. > >>> > >>> Seriously, don't you see how hairy all this is? And for what? Nitpicking > >>> something that doesn't seem to be a real problem in the first place? > >> > >> Seriously, can't you find "zonelist_update_seq is not checked by !__GFP_DIRECT_RECLAIM > >> allocations, which is a low-hanging fruit towards GFP_LOCKLESS" !? > > > > I do not think we have concluded that we want to support GFP_LOCKLESS. > > This might be trivial straightforward now but it imposes some constrains > > for future maintainability. So far we haven't heard about many usecases > > where this would be needed and a single one is not sufficient IMHO. > > When you introduced a word GFP_LOCKLESS in the link above, I was wondering the meaning > of "LESS" part. Since we know that it is difficult to achieve "hold 0 lock during memory > allocation", "hold least locks during memory allocation" will be at best. Therefore, > GFP_LOCKLESS is as misleading name as GFP_ATOMIC. GFP_LOCK_LEAST or GFP_LEAST_LOCKS will > represent the real behavior better. I am not sure I understand what least locks mean actually. I guess what you wanted to say is that there are no locks or other synchronization means with external visibility/dependencies used. In other words a mode which can be called from any locking context. That would be certainly possible and whether any internal locks are used or not is an implementation detail as long as the no external visibility/dependencies rule is held. I do not really want to start the naming discussion as it is not really clear we want/need to provide such a strong guarantee. -- Michal Hocko SUSE Labs