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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 589FDC433E1 for ; Thu, 13 Aug 2020 17:22:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 19ADC20716 for ; Thu, 13 Aug 2020 17:22:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 19ADC20716 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 91D538D0001; Thu, 13 Aug 2020 13:22:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A5DE6B0024; Thu, 13 Aug 2020 13:22:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76E188D0001; Thu, 13 Aug 2020 13:22:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 5C6746B000E for ; Thu, 13 Aug 2020 13:22:40 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1259E181AEF15 for ; Thu, 13 Aug 2020 17:22:40 +0000 (UTC) X-FDA: 77146214880.22.trail37_1b007b226ff5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id D536118038E60 for ; Thu, 13 Aug 2020 17:22:39 +0000 (UTC) X-HE-Tag: trail37_1b007b226ff5 X-Filterd-Recvd-Size: 2819 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Aug 2020 17:22:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 83168B676; Thu, 13 Aug 2020 17:23:00 +0000 (UTC) Date: Thu, 13 Aug 2020 19:22:37 +0200 From: Michal Hocko To: Thomas Gleixner Cc: Uladzislau Rezki , paulmck@kernel.org, LKML , RCU , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Matthew Wilcox , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko , Peter Zijlstra Subject: Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag Message-ID: <20200813172237.GU9477@dhcp22.suse.cz> References: <20200811210931.GZ4295@paulmck-ThinkPad-P72> <874kp87mca.fsf@nanos.tec.linutronix.de> <20200813075027.GD9477@dhcp22.suse.cz> <20200813095840.GA25268@pc636> <874kp6llzb.fsf@nanos.tec.linutronix.de> <20200813133308.GK9477@dhcp22.suse.cz> <87sgcqty0e.fsf@nanos.tec.linutronix.de> <20200813145335.GN9477@dhcp22.suse.cz> <87lfiitquu.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lfiitquu.fsf@nanos.tec.linutronix.de> X-Rspamd-Queue-Id: D536118038E60 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Thu 13-08-20 19:09:29, Thomas Gleixner wrote: > Michal Hocko writes: > > On Thu 13-08-20 16:34:57, Thomas Gleixner wrote: [...] I will go though the rest of the email tomorrow. > >> Really, if your primary lockless caches are empty then any allocation > >> which comes from deep atomic context should simply always fail. Being > >> stuck in an interrupt handler or even deeper for 200+ microseconds > >> waiting for zone lock is just bonkers IMO. > > > > That would require changing NOWAIT/ATOMIC allocations semantic quite > > drastically for !RT kernels as well. I am not sure this is something we > > can do. Or maybe I am just missing your point. > > I really do not understand why you think that it affects everything. We are likely not on the same page here. Are you talking about the original proposal in this thread (aka a new flag) or a way to reuse existing gfp space (http://lkml.kernel.org/r/20200813075027.GD9477@dhcp22.suse.cz) with a modification that would both silence the lockdep and keep the existing NOWAIT semantic? Sorry bear with me but I am getting lost in this thread. -- Michal Hocko SUSE Labs