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 56484C04A94 for ; Fri, 4 Aug 2023 13:28:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 662D28D0013; Fri, 4 Aug 2023 09:28:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 612AC8D0006; Fri, 4 Aug 2023 09:28:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DA988D0013; Fri, 4 Aug 2023 09:28:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3F22C8D0006 for ; Fri, 4 Aug 2023 09:28:29 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 04A39B3230 for ; Fri, 4 Aug 2023 13:28:28 +0000 (UTC) X-FDA: 81086501538.10.263E58D Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf06.hostedemail.com (Postfix) with ESMTP id 6A101180005 for ; Fri, 4 Aug 2023 13:28:26 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=none (imf06.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691155707; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2EKr41WM0JCER9RY7vlE/rW4XxqL9PlOnk4TbPgdnRY=; b=Me/usPEp/m4fuofDmP9HGRLVW0ysV5AnXxHGu3aC5nPWyAxc6BAqfpbs4H7CXkDt+epK35 Wk+FmiE/9eo4pLXITPdjz4VcKErGQWVpbsDzr9DiVwSo04rPYmtHY2dyu1bsAsvYtWMoNv V2BuFTQO30cEAXKahycsEKrT9mbiMKM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=none; spf=none (imf06.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691155707; a=rsa-sha256; cv=none; b=7dYnE6rZgEGokBbdnZ9TZ29Hq/Ra+NlOckzfJNI3MsnLz9gtqXGS0k78yxF9bWxiEyFhLC jitT0IKYPo/+W1ec7c0xmu3gf0Bf/DYQ0Yb1AInoWCSEOzWJyKGQw66T4A2nBlgjbDWrPC Kwfx+fOhcLSbTKXIycF+4RB7FEHC7H0= Received: from fsav412.sakura.ne.jp (fsav412.sakura.ne.jp [133.242.250.111]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 374DRMAA042544; Fri, 4 Aug 2023 22:27:22 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav412.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav412.sakura.ne.jp); Fri, 04 Aug 2023 22:27:22 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav412.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 374DRLxE042538 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Aug 2023 22:27:22 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <2505f6d3-5a10-49e7-960f-12c31a62a366@I-love.SAKURA.ne.jp> Date: Fri, 4 Aug 2023 22:27:22 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Content-Language: en-US To: Michal Hocko , Sebastian Andrzej Siewior , Andrew Morton Cc: 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 References: <20230623171232.892937-2-bigeasy@linutronix.de> <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> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6A101180005 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: zqqiizh9w8a57azuaafuykmewohmk1oc X-HE-Tag: 1691155706-720619 X-HE-Meta: U2FsdGVkX19zr/ExXy7kwcRrhGohH8aFw+uVwG3Jj3V+0ld89t4PvtXfm6KBpBAtxvoUgBsM3hOoD+Bhn60GFAJXzGwPznL0drqnmabPicp4TBXhH1xO1DrO04ZPwGBPI+AgA/KUrTYEdNddfwgg+HemEGoQSpWLSRBt9/GOr8pfb0QOqArwSapGxAza1v52YAt53bA4qvEyeHhvd4LD2NbS1Lck/vtcakUy/WkNPCOhvDqREqsf0cJ7xlA91Hj0SxMUbudhrLiADaSAsNDB+6lBuHjld8YTHQWk+0zHHrOCWTDI2DzmQ1N/hhu+NHgjSNSEXa5pi5zgm+mvsmDFnM/mWVKchm9OGmqSrYOVGSe/qT29Ds9kO2TdD8k844gw62JvBplfK9PTkBy+YNlXzlIBHtjiRnNOIdgvDtKJBSL09oAmdFkXyQh5LIFmidAQl0SFPRysyfMZp/AVO67me2W7FyYeTBrqMDn75O0/ydZujjLIEBjLw/xpwnZDOlm4tB5FB9JUP9dAyyG3j/aOht+yNU+5gsdtn1O2K0KRYNkF6GY7vc155WgReO3hk6v7vQANKB8MwPih91PCX2C6BiWTzcxAWGrCu7z5K9nitvrRa3z22aQTWvd+6fMcW5N9JasMle1xbGz+MYMI+TPle+MXQYz9G8em1DkIXK6CrHMHGeHhvUgNFJhhezf13vTOPtJoZRL/vHkO0ZXGIyHgkNdxUvikNKtGU1/6/QpxNcji5y5CMu6eRW1nTeLEOQYPKBYDs+aG4MmrdNDvO1/jZgSdfwTkrs+0okeUZQF9js4xgrwjdapZA6aFAc6bjv3hncs+ms8bnsqXfWMB+aAPTYKdaR2yU+d1wXU0scTIIP3tSmCzUKSJOIfrEHPDJvWub7XUGIDEaXFRqG/avKwam/TGAncKmwW1JZfVwP5JeJPV7qDGy+2hkCUawTiBcWXaBegIPjSgQ8FA51r6Mp0 eoZaDWlq Qr4yBVSecC32/qsnF49XBNB425URrZlRKNE3C3prAtK8eWAEs4PQVhYN5DJzYyTadzEQ7lwE0nOCBO7XA2ibqoVqLPnT7bMGdB9VYlJjOdKW9QfNusvv1jGYDinLYjIwkWC1S5UMbCDuMnsoeV+TWLTWSzatQdv0AX9761vd7HD1sAn73TJHgIQyVw/2eHw484+NP3MJCZr6vlqUNJTXsBkvUU6rcMIsbZK3yBMxDf8+IIxwm2YliXYMJ7mbkE7PtbksmvgD4nfpIfFUHKypR4pEhscrpHL07DlZiuwi/j0d+EfOLLTU0anfcauBGt8YnAYrjpQm9WdQouuU= 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 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. Like I said I consider that memory allocations which do not do direct reclaim should be geared towards less locking dependency. in the thread above, I still believe that this what-you-call-hairy version (which matches "hold least locks during memory allocation" direction) is better than "[PATCH v3 2/2] mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save()." (which does not match "hold least locks during memory allocation"). My version not only avoids possibility of deadlock, but also makes zonelist_iter_begin() faster and simpler. Not holding zonelist_update_seq lock is trivially doable compared to removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC. Please give me feedback about which line of my proposal is technically unsafe, instead of discarding my proposal with negative words like "hairy".