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 09DF3C433F5 for ; Mon, 10 Jan 2022 15:01:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C2136B0073; Mon, 10 Jan 2022 10:01:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 64A8D6B0074; Mon, 10 Jan 2022 10:01:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49DAF6B0075; Mon, 10 Jan 2022 10:01:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id 3282A6B0073 for ; Mon, 10 Jan 2022 10:01:22 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E57CB9677F for ; Mon, 10 Jan 2022 15:01:21 +0000 (UTC) X-FDA: 79014690762.20.D13FCAA Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf10.hostedemail.com (Postfix) with ESMTP id C91FFC0044 for ; Mon, 10 Jan 2022 15:01:15 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 8EAE91F393; Mon, 10 Jan 2022 15:01:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1641826874; 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=Q76Wyz+nI4/dcgRGawE+N5Thsz9mJBqCX+eGoAKYvPo=; b=CjkZ7+V6QTNv2Tsl/GKUB9gnqie3olVoeDmQa34/K9GA1F/u0kSpjWeWi6Znj+zn0Xhc+Q TTR2PoDZZJlwaJ/Cz0NbTu4lHYo3gmSCGkVRQQIOizAZwyl3SgmuzPls/PNH7T5LQ4wLe+ c3NzO7AP8oqw2TD+h9vA+JKojRFbpVE= 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 B8613A3B87; Mon, 10 Jan 2022 15:01:13 +0000 (UTC) Date: Mon, 10 Jan 2022 16:01:13 +0100 From: Michal Hocko To: Yu Zhao Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, page-reclaim@google.com, x86@kernel.org, Konstantin Kharlamov Subject: Re: [PATCH v6 6/9] mm: multigenerational lru: aging Message-ID: References: <20220104202227.2903605-1-yuzhao@google.com> <20220104202227.2903605-7-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C91FFC0044 X-Stat-Signature: ocqhqza5km9fxa9zgqw5pmxhj9e1hub3 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=CjkZ7+V6; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf10.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1641826875-650516 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 06-01-22 17:12:18, Michal Hocko wrote: > On Tue 04-01-22 13:22:25, Yu Zhao wrote: > > +static struct lru_gen_mm_walk *alloc_mm_walk(void) > > +{ > > + if (!current->reclaim_state || !current->reclaim_state->mm_walk) > > + return kvzalloc(sizeof(struct lru_gen_mm_walk), GFP_KERNEL); One thing I have overlooked completely. You cannot really use GFP_KERNEL allocation here because the reclaim context can be constrained (e.g. GFP_NOFS). This allocation will not do any reclaim as it is PF_MEMALLOC but I suspect that the lockdep will complain anyway. Also kvmalloc is not really great here. a) vmalloc path is never executed for small objects and b) we do not really want to make a dependency between vmalloc and the reclaim (by vmalloc -> reclaim -> vmalloc). Even if we rule out vmalloc and look at kmalloc alone. Is this really safe? I do not see any recursion prevention in the SL.B code. Maybe this just happens to work but the dependency should be really documented so that future SL.B changes won't break the whole scheme. -- Michal Hocko SUSE Labs