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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C34B5C433F5 for ; Wed, 20 Oct 2021 09:18:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5708C61074 for ; Wed, 20 Oct 2021 09:18:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5708C61074 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DDCF36B0071; Wed, 20 Oct 2021 05:18:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8D06900002; Wed, 20 Oct 2021 05:18:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5F946B0073; Wed, 20 Oct 2021 05:18:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id B753E6B0071 for ; Wed, 20 Oct 2021 05:18:17 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 750F22C59A for ; Wed, 20 Oct 2021 09:18:17 +0000 (UTC) X-FDA: 78716264634.31.000871B Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf30.hostedemail.com (Postfix) with ESMTP id EEA34E0016BB for ; Wed, 20 Oct 2021 09:18:11 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id DADA321A95; Wed, 20 Oct 2021 09:18:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1634721495; 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=BPvjtKQOd7fMC/9/+8JIUhUxh+2Qtv3moJhg8NLiHcw=; b=awmXIrfSpc3o/SPaF6WaZAChHlN33ooMtYKNDMhPf/HHkoQk7qfj/Q/spZ5DhVbgTIOoin a2M69P4ECgh8NtrjfRAlZWAqyPTGO1qAFnttsXBpQqEDzzFAjLHG/a1X4dJ1kUlIaMJ3LB SARONEeIU6m24Y5NKJ46AJbENt2wuY4= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A8187A3B81; Wed, 20 Oct 2021 09:18:15 +0000 (UTC) Date: Wed, 20 Oct 2021 11:18:15 +0200 From: Michal Hocko To: Uladzislau Rezki Cc: linux-mm@kvack.org, Dave Chinner , Neil Brown , Andrew Morton , Christoph Hellwig , linux-fsdevel@vger.kernel.org, LKML , Ilya Dryomov , Jeff Layton Subject: Re: [RFC 2/3] mm/vmalloc: add support for __GFP_NOFAIL Message-ID: References: <20211018114712.9802-1-mhocko@kernel.org> <20211018114712.9802-3-mhocko@kernel.org> <20211019110649.GA1933@pc638.lan> <20211019194658.GA1787@pc638.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: thauwsnpp939xee51hzgp738wd3hrn8p X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EEA34E0016BB Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=awmXIrfS; spf=pass (imf30.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 X-HE-Tag: 1634721491-98785 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 20-10-21 10:25:06, Michal Hocko wrote: [...] > > > The flag itself is not really necessary down there as long as we > > > guarantee that the high level logic doesn't fail. In this case we keep > > > retrying at __vmalloc_node_range level which should be possible to cover > > > all callers that can control gfp mask. I was thinking to put it into > > > __get_vm_area_node but that was slightly more hairy and we would be > > > losing the warning which might turn out being helpful in cases where the > > > failure is due to lack of vmalloc space or similar constrain. Btw. do we > > > want some throttling on a retry? > > > > > I think adding kind of schedule() will not make things worse and in corner > > cases could prevent a power drain by CPU. It is important for mobile devices. > > I suspect you mean schedule_timeout here? Or cond_resched? I went with a > later for now, I do not have a good idea for how to long to sleep here. > I am more than happy to change to to a sleep though. Forgot to paste the follow up I have staged currently --- commit 66fea55e5543fa234692a70144cd63c7a1bca32f Author: Michal Hocko Date: Wed Oct 20 10:12:45 2021 +0200 fold me "mm/vmalloc: add support for __GFP_NOFAIL" - add cond_resched diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 0fb5413d9239..f7098e616883 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2944,6 +2944,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, do { ret = vmap_pages_range(addr, addr + size, prot, area->pages, page_shift); + cond_resched(); } while ((gfp_mask & __GFP_NOFAIL) && (ret < 0)); if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO) @@ -3034,8 +3035,10 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align, warn_alloc(gfp_mask, NULL, "vmalloc error: size %lu, vm_struct allocation failed", real_size); - if (gfp_mask & __GFP_NOFAIL) + if (gfp_mask & __GFP_NOFAIL) { + cond_resched(); goto again; + } goto fail; } -- Michal Hocko SUSE Labs