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 09243C433F5 for ; Sun, 26 Dec 2021 17:57:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 318926B0074; Sun, 26 Dec 2021 12:57:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C7E76B0075; Sun, 26 Dec 2021 12:57:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 167FA6B0078; Sun, 26 Dec 2021 12:57:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id 039FF6B0074 for ; Sun, 26 Dec 2021 12:57:22 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A61BD86E80 for ; Sun, 26 Dec 2021 17:57:21 +0000 (UTC) X-FDA: 78960702282.26.87AC936 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf05.hostedemail.com (Postfix) with ESMTP id 47CBD100019 for ; Sun, 26 Dec 2021 17:57:21 +0000 (UTC) Received: by mail-lf1-f50.google.com with SMTP id bt1so30161811lfb.13 for ; Sun, 26 Dec 2021 09:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Y/KMILrBq1hPy+xDvjqcSHV2HcfoucjLDA3+9/tMVT0=; b=F0t5qpmstEAZj0YEL1wM8elsvrt/rZJ0nL/KElvIKruFcShSjvtBudTODxDs7Tj/qg katgz/y/08xD5MWchIBOB5RfH6Z6CWi5jm91Fw3uVAxLX51s536922ajRdxqGeBIe3kP KTRsuzNPIf6iCUQNHSYB5RSnt2Wep0FMQ9h/R+/UiqlTvZK6CVxBinOZSrhu3f/et/f4 03FWQaKDTC36HF73ay5n7cK2pAeJ7xqBDU7WaEQJbULp3AlG6i/8tDTuP+skXRIKykoV GOlWx8OvRDMqlb6LNjSwntdY+49NEXE0go3xeAfAq4uvZ7rH0Q5Jw/tqRpL54o+Gpr9k SgDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Y/KMILrBq1hPy+xDvjqcSHV2HcfoucjLDA3+9/tMVT0=; b=B94fj+QA6R9M+ZB3CQRkIl+/NHMp7nAgo1h2aZa07DYPeo0zBJO0opIJgbVVU2DXfM Zj+l/EyozssFnj3fopdBGo2kw9853zPpHHygLqBPr5z2XLvHUbS0IIZcw5RL79qIpmrP Q8ls93CTtV/+2n380SQ+H7uGUJ/bPt1lkrlOJzMz/FY05bb5R8khJ3IxAUYo2AT63KIe TbuGxsxIR4AXdR5vjFFhI9jncJ7LIsIHr0OWkbXBxDTkFpRNGYiokqEwJgZhg2UNJckI elwHmnU5fViLIgoPn8lewGHHDL/KSxo5bYvUNiJW3ifuPydEincalyKNb+rXQTA+e3Jk 1H4Q== X-Gm-Message-State: AOAM531Lig/jeLVysGTh/reITK96E+z3T3rFs/6Fhl2MlViszJTQy0od ptDRLM+NiPOrLMtCM2hJghg= X-Google-Smtp-Source: ABdhPJxHdN9lbBkDQFqp2UaQueYrnTWdb/e/F2F1erX8MpQ5lc9Sq840sBcXsiifAnW2MXF/QdkS4w== X-Received: by 2002:a05:6512:11cf:: with SMTP id h15mr12606157lfr.138.1640541439634; Sun, 26 Dec 2021 09:57:19 -0800 (PST) Received: from pc638.lan (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id m13sm844312lfg.139.2021.12.26.09.57.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Dec 2021 09:57:18 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Sun, 26 Dec 2021 18:57:16 +0100 To: Matthew Wilcox Cc: Uladzislau Rezki , Manfred Spraul , LKML , Andrew Morton , Vasily Averin , cgel.zte@gmail.com, shakeelb@google.com, rdunlap@infradead.org, dbueso@suse.de, unixbhaskar@gmail.com, chi.minghao@zte.com.cn, arnd@arndb.de, Zeal Robot , linux-mm@kvack.org, 1vier1@web.de, stable@vger.kernel.org Subject: Re: [PATCH] mm/util.c: Make kvfree() safe for calling while holding spinlocks Message-ID: References: <20211222194828.15320-1-manfred@colorfullife.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=F0t5qpms; spf=pass (imf05.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 47CBD100019 X-Stat-Signature: 1a9h8cbckjzyo8hpbsbo88ybyrt1kcwo X-HE-Tag: 1640541441-861972 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 Sat, Dec 25, 2021 at 10:58:29PM +0000, Matthew Wilcox wrote: > On Sat, Dec 25, 2021 at 07:54:12PM +0100, Uladzislau Rezki wrote: > > +static void drain_vmap_area(struct work_struct *work) > > +{ > > + if (mutex_trylock(&vmap_purge_lock)) { > > + __purge_vmap_area_lazy(ULONG_MAX, 0); > > + mutex_unlock(&vmap_purge_lock); > > + } > > +} > > + > > +static DECLARE_WORK(drain_vmap_area_work, drain_vmap_area); > > Presuambly if the worker fails to get the mutex, it should reschedule > itself? And should it even trylock or just always lock? > mutex_trylock() has no sense here. It should just always get the lock. Otherwise we can miss the point to purge. Agree with your opinion. > > This kind of ties into something I've been wondering about -- we have > a number of places in the kernel which cache 'freed' vmalloc allocations > in order to speed up future allocations of the same size. Kind of like > slab. Would we be better off trying to cache frequent allocations > inside vmalloc instead of always purging them? > Hm... Some sort of caching would be good. Though it will require some time to think over all details and design itself. We can cache VAs instead of purging them until some point or threshold. So basically we can keep it in our data structures, associate it with some cache, based on size and reuse it later in the alloc_vmap_area(). All that is related to "vmap_area" caching. Another option is to cache the "vm_struct". It includes "vmap_area" + pages to drive the mapping. It is a higher level of caching and i am not sure if an implementation would be so straightforward. -- Vlad Rezki