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 X-Spam-Level: X-Spam-Status: No, score=-16.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 642ADC48BC2 for ; Wed, 23 Jun 2021 17:30:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B26F608FE for ; Wed, 23 Jun 2021 17:30:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B26F608FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D6E1D6B0011; Wed, 23 Jun 2021 13:30:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D1EBA6B005D; Wed, 23 Jun 2021 13:30:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBF5B6B006C; Wed, 23 Jun 2021 13:30:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id 87AFF6B0011 for ; Wed, 23 Jun 2021 13:30:15 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A3935181AEF1A for ; Wed, 23 Jun 2021 17:30:15 +0000 (UTC) X-FDA: 78285677190.14.00DC702 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 2E7C44000392 for ; Wed, 23 Jun 2021 17:30:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624469414; h=from:from:reply-to:subject:subject: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=RP1VcIqhLwFYXzXkWr2dt9Vgt97hFXb+2xz/b6BZuvI=; b=FdBe88iW3neQLUPkwj38SqGTGIti4skJodUrE5OiraRdNQRA938CoHp7eVfvxyUqd3MfBl CcU5mRlkhwJIANVUOoSA7UFHyJeqAPjO5vZyRLuqVgK7m8UsKP0FmtByJX6hnU6vcplh6B 2Z1VgxvvQWhzVRu75LZiyCzPttZSt/0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-147-CwMQLns0NR-mTlo94ck5sw-1; Wed, 23 Jun 2021 13:30:12 -0400 X-MC-Unique: CwMQLns0NR-mTlo94ck5sw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7D1F09126F; Wed, 23 Jun 2021 17:30:11 +0000 (UTC) Received: from optiplex-fbsd (unknown [10.3.128.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC66860583; Wed, 23 Jun 2021 17:30:09 +0000 (UTC) Date: Wed, 23 Jun 2021 13:30:07 -0400 From: Rafael Aquini To: Nicholas Piggin Cc: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: vmalloc: add cond_resched() in __vunmap() Message-ID: References: <20210622225030.478384-1-aquini@redhat.com> <1624437661.tyds6vli52.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1624437661.tyds6vli52.astroid@bobo.none> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FdBe88iW; spf=none (imf10.hostedemail.com: domain of aquini@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=aquini@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2E7C44000392 X-Stat-Signature: 9mfm9z5bk65itu8cg64s74ro3n9h7bij X-HE-Tag: 1624469415-251344 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, Jun 23, 2021 at 06:43:50PM +1000, Nicholas Piggin wrote: > Excerpts from Rafael Aquini's message of June 23, 2021 8:50 am: > > On non-preemptible kernel builds the watchdog can complain > > about soft lockups when vfree() is called against large > > vmalloc areas: > > > > [ 210.851798] kvmalloc-test: vmalloc(2199023255552) succeeded > > This is vfreeing()ing 2TB of memory? Maybe not too realistic but > I guess it doesn't hurt to add. > Andrew has recently addressed https://bugzilla.kernel.org/show_bug.cgi?id=210023 via 34fe653716b0d ("mm/vmalloc.c:__vmalloc_area_node(): avoid 32-bit overflow") The person that filed that bug also filed a case requesting the issue to be addressed in RHEL. So the case for large vmaps such as that one in the test case is real, albeit not being a frequent use case perhaps. Realistically, though, that vunmap loop can still burn considerable amount of CPU time, even when vfreeing smaller areas, thus as you well noted, it's better to play nice and back off a bit and let others having a chance to run as well. > Acked-by: Nicholas Piggin Thanks! -- Rafael > Thanks, > Nick > > > [ 238.654842] watchdog: BUG: soft lockup - CPU#181 stuck for 26s! [rmmod:5203] > > [ 238.662716] Modules linked in: kvmalloc_test(OE-) ... > > [ 238.772671] CPU: 181 PID: 5203 Comm: rmmod Tainted: G S OE 5.13.0-rc7+ #1 > > [ 238.781413] Hardware name: Intel Corporation PURLEY/PURLEY, BIOS PLYXCRB1.86B.0553.D01.1809190614 09/19/2018 > > [ 238.792383] RIP: 0010:free_unref_page+0x52/0x60 > > [ 238.797447] Code: 48 c1 fd 06 48 89 ee e8 9c d0 ff ff 84 c0 74 19 9c 41 5c fa 48 89 ee 48 89 df e8 b9 ea ff ff 41 f7 c4 00 02 00 00 74 01 fb 5b <5d> 41 5c c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f0 29 77 > > [ 238.818406] RSP: 0018:ffffb4d87868fe98 EFLAGS: 00000206 > > [ 238.824236] RAX: 0000000000000000 RBX: 000000001da0c945 RCX: ffffb4d87868fe40 > > [ 238.832200] RDX: ffffd79d3beed108 RSI: ffffd7998501dc08 RDI: ffff9c6fbffd7010 > > [ 238.840166] RBP: 000000000d518cbd R08: ffffd7998501dc08 R09: 0000000000000001 > > [ 238.848131] R10: 0000000000000000 R11: ffffd79d3beee088 R12: 0000000000000202 > > [ 238.856095] R13: ffff9e5be3eceec0 R14: 0000000000000000 R15: 0000000000000000 > > [ 238.864059] FS: 00007fe082c2d740(0000) GS:ffff9f4c69b40000(0000) knlGS:0000000000000000 > > [ 238.873089] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 238.879503] CR2: 000055a000611128 CR3: 000000f6094f6006 CR4: 00000000007706e0 > > [ 238.887467] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > [ 238.895433] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > [ 238.903397] PKRU: 55555554 > > [ 238.906417] Call Trace: > > [ 238.909149] __vunmap+0x17c/0x220 > > [ 238.912851] __x64_sys_delete_module+0x13a/0x250 > > [ 238.918008] ? syscall_trace_enter.isra.20+0x13c/0x1b0 > > [ 238.923746] do_syscall_64+0x39/0x80 > > [ 238.927740] entry_SYSCALL_64_after_hwframe+0x44/0xae > > > > Like in other range zapping routines that iterate over > > a large list, lets just add cond_resched() within __vunmap()'s > > page-releasing loop in order to avoid the watchdog splats. > > > > Signed-off-by: Rafael Aquini > > --- > > mm/vmalloc.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index a13ac524f6ff..cd4b23d65748 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -2564,6 +2564,7 @@ static void __vunmap(const void *addr, int deallocate_pages) > > > > BUG_ON(!page); > > __free_pages(page, page_order); > > + cond_resched(); > > } > > atomic_long_sub(area->nr_pages, &nr_vmalloc_pages); > > > > -- > > 2.26.3 > > > > > > >