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 67330C433F5 for ; Wed, 6 Apr 2022 09:13:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E581E6B0072; Wed, 6 Apr 2022 05:13:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DFCCC6B0073; Wed, 6 Apr 2022 05:13:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEB8E6B0074; Wed, 6 Apr 2022 05:13:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id C05CB6B0072 for ; Wed, 6 Apr 2022 05:13:32 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7DBC1183E46D6 for ; Wed, 6 Apr 2022 09:13:22 +0000 (UTC) X-FDA: 79325890644.29.BB8EAA9 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf12.hostedemail.com (Postfix) with ESMTP id D90004002A for ; Wed, 6 Apr 2022 09:13:21 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id b17so3008615lfv.3 for ; Wed, 06 Apr 2022 02:13:21 -0700 (PDT) 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:content-transfer-encoding:in-reply-to; bh=N2Z6vFlTmCq7+74XFJ64TwoBo1hcgujD04OAAxLb788=; b=Uh7HSpYbYxI3V+zmXUQe6hY1jGKSnCCUXf9Ib1wZUMpiMpv6tKfitjYq2aNYDQU1q2 Sgj28B1qeesTKO6hnSioljD0v+HDH0MyyyMgPKIprCwY1SX5qEx4AvRxaH5qPsDiSIPy VcQijJNXFu3vr5CwynY2tz84ZsHZ0yjO63kzCVT1ICm/j3bnwr7hzsFUVFu1RjDoeunM Wm6CWI7maiidblfmNs09NGjc9r536L9lTrKj6TU+D1+1o63o54gxEMDrkAW4SxrErJ+E Fy3xOo8Oc/Sl6K3WLsJMpVMRQ7T0wAiLaN8JxNVLbiaWDztmeSapthJZUi6PAgcrBs4g 7S5w== 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:content-transfer-encoding :in-reply-to; bh=N2Z6vFlTmCq7+74XFJ64TwoBo1hcgujD04OAAxLb788=; b=5caN9e2SlLy6gefgyFLFX4i16hIPQOkesG/vTHF/zcos6vWkVonxC1Uox8fFaQ0r58 H8T9z7bqB2qCSqOu0WDYqQyLjiHCCbt3GFX0kcmLfKjvBJsMjh/lf+2XFEJxcldiuGVP 5geF6BLksVQnDaPKZ+SWnBCLpiElP44hB01JchPTOk0IowK8NnAfO0+gb1+SBh/3EIXJ DURSraKRmWtuvs4Gtvm6UJLVr3SifBcq+f3HXq922jdNOqlgWkQhkQ8i4VxnPTZAStj5 4XX7buN9fPVoWdPIQF11rkXEHLBQp4c/3tFn/j+gYn6GDWoWnBfo2Eun1jQQMAi7DgFP Q5fg== X-Gm-Message-State: AOAM532S6JMmy7K5/sNYYItfealctW5ZrSbCRU85iMeMyb8NWLEm5PPv N0DznHThKcdgMOZ6dJ0QRAQ= X-Google-Smtp-Source: ABdhPJwis/WS1Ka689EbX4W5MQ3qrOgszTeUA+2nAp3uGP19qNwLIvGhbhOwcOXM7HN2HExQ5EBqGA== X-Received: by 2002:a05:6512:260d:b0:448:35d2:f72a with SMTP id bt13-20020a056512260d00b0044835d2f72amr5330482lfb.515.1649236400029; Wed, 06 Apr 2022 02:13:20 -0700 (PDT) Received: from pc638.lan ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id x23-20020a056512131700b004486c863c8esm1768607lfu.257.2022.04.06.02.13.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 02:13:19 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 6 Apr 2022 11:13:17 +0200 To: Christoph Hellwig , Omar Sandoval Cc: Omar Sandoval , linux-mm@kvack.org, kexec@lists.infradead.org, Andrew Morton , Uladzislau Rezki , Cliff Wickman , x86@kernel.org, kernel-team@fb.com Subject: Re: [PATCH] mm/vmalloc: fix spinning drain_vmap_work after reading from /proc/vmcore Message-ID: References: <75014514645de97f2d9e087aa3df0880ea311b77.1649187356.git.osandov@fb.com> <20220406044244.GA9959@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220406044244.GA9959@lst.de> X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Uh7HSpYb; spf=pass (imf12.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D90004002A X-Stat-Signature: gp8dyj6a4ofujnemydtxxhzsrsategxd X-HE-Tag: 1649236401-515523 Content-Transfer-Encoding: quoted-printable 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 Tue, Apr 05, 2022 at 12:40:31PM -0700, Omar Sandoval wrote: > > A simple way to "fix" this would be to make set_iounmap_nonlazy() set > > vmap_lazy_nr to lazy_max_pages() instead of lazy_max_pages() + 1. But= , I > > think it'd be better to get rid of this hack of clobbering vmap_lazy_= nr. > > Instead, this fix makes __copy_oldmem_page() explicitly drain the vma= p > > areas itself. >=20 > This fixes the bug and the interface also is better than what we had > before. But a vmap/iounmap_eager would seem even better. But hey, > right now it has one caller in always built =D1=96n x86 arch code, so m= aybe > it isn't worth spending more effort on this. > IMHO, it just makes sense to remove it. The set_iounmap_nonlazy() was added in 2010 year: commit 3ee48b6af49cf534ca2f481ecc484b156a41451d Author: Cliff Wickman Date: Thu Sep 16 11:44:02 2010 -0500 mm, x86: Saving vmcore with non-lazy freeing of vmas During the reading of /proc/vmcore the kernel is doing ioremap()/iounmap() repeatedly. And the buildup of un-flushed vm_area_struct's is causing a great deal of overhead. (rb_next() is chewing up most of that time). This solution is to provide function set_iounmap_nonlazy(). It causes a subsequent call to iounmap() to immediately purge the vma area (with try_purge_vmap_area_lazy()). With this patch we have seen the time for writing a 250MB compressed dump drop from 71 seconds to 44 seconds. Signed-off-by: Cliff Wickman Cc: Andrew Morton Cc: kexec@lists.infradead.org Cc: LKML-Reference: Signed-off-by: Ingo Molnar and the reason was the "slow vmap" code, i.e. due to poor performance they decided to drop the lazily ASAP. Now we have absolutely different picture when it comes to performance and the vmalloc/vmap code. Any thoughts? -- Uladzislau Rezki