From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [patch 00/13] preempt: Make preempt count unconditional Date: Tue, 29 Sep 2020 11:00:03 +0200 Message-ID: <20200929090003.GG438822@phenom.ffwll.local> References: <871rj4owfn.fsf@nanos.tec.linutronix.de> <87bli75t7v.fsf@nanos.tec.linutronix.de> <20200916152956.GV29330@paulmck-ThinkPad-P72> <20200916205840.GD29330@paulmck-ThinkPad-P72> <20200929081938.GC22035@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=l8n+Qtmools068Op1SBkscZ3rmiXf/OnO40zpDWJvQs=; b=HSfJ7A4FNQbt4jfghWagnZ0q3COkKg8qz4BPThTLTJ7eDRMt1DvHHeb7XKEZ522gOH eWGtprOnXgZp5uEMLqACAESKMKR8I99jBaCAbi8CJzl/OnYlzX1P6crhIyasKLf4c1bf 2XybbZVEohhAC+dLedQmm8E/GOTp7GyR5iP8M= Content-Disposition: inline In-Reply-To: <20200929081938.GC22035@dhcp22.suse.cz> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Michal Hocko Cc: Juri Lelli , Peter Zijlstra , Sebastian Andrzej Siewior , Lai Jiangshan , dri-devel , Ben Segall , Linux-MM , "open list:KERNEL SELFTEST FRAMEWORK" , Will Deacon , Ard Biesheuvel , Anton Ivanov , linux-arch , Herbert Xu , Brian Cain , linux-hexagon@vger.kernel.org, Russell King , Ingo Molnar , David Airlie , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , Matt Turner , Valentin Schneider On Tue, Sep 29, 2020 at 10:19:38AM +0200, Michal Hocko wrote: > On Wed 16-09-20 23:43:02, Daniel Vetter wrote: > > I can > > then figure out whether it's better to risk not spotting issues with > > call_rcu vs slapping a memalloc_noio_save/restore around all these > > critical section which force-degrades any allocation to GFP_ATOMIC at > > did you mean memalloc_noreclaim_* here? Yeah I picked the wrong one of that family of functions. > > most, but has the risk that we run into code that assumes "GFP_KERNEL > > never fails for small stuff" and has a decidedly less tested fallback > > path than rcu code. > > Even if the above then please note that memalloc_noreclaim_* or > PF_MEMALLOC should be used with an extreme care. Essentially only for > internal memory reclaimers. It grants access to _all_ the available > memory so any abuse can be detrimental to the overall system operation. > Allocation failure in this mode means that we are out of memory and any > code relying on such an allocation has to carefuly consider failure. > This is not a random allocation mode. Agreed, that's why I don't like having these kind of automagic critical sections. It's a bit a shotgun approach. Paul said that the code would handle failures, but the problem is that it applies everywhere. Anyway my understanding is that call_rcu will be reworked and gain a pile of tricks so that these problems for the callchains leading to call_rcu all disappear. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch