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=-5.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 4CF91C2D0A3 for ; Mon, 9 Nov 2020 11:34:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AD0DC206ED for ; Mon, 9 Nov 2020 11:34:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dq3aUSf9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD0DC206ED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D10376B005D; Mon, 9 Nov 2020 06:34:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CE60E6B0068; Mon, 9 Nov 2020 06:34:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFD576B006C; Mon, 9 Nov 2020 06:34:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id 9472F6B005D for ; Mon, 9 Nov 2020 06:34:05 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 478B2180AD802 for ; Mon, 9 Nov 2020 11:34:05 +0000 (UTC) X-FDA: 77464670850.25.pigs04_2800a69272ec Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 201E31804E3A0 for ; Mon, 9 Nov 2020 11:34:05 +0000 (UTC) X-HE-Tag: pigs04_2800a69272ec X-Filterd-Recvd-Size: 7325 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Nov 2020 11:34:04 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id v20so1338059ljk.8 for ; Mon, 09 Nov 2020 03:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=JPw2Po3K5j1KcfJ68+mIpcS7q1fw1SYnoLWr5LV7uxE=; b=dq3aUSf99CRTkXSToJ1pqxR5JNG/JS2MMvBEU6YU0hSvgbQNcoeXBF2o5MqBlho7HT oBZcM+0wqN7wpasKU+Jng8i1uX3C6L15DK1aduROulVcO0KOWEpHREIWvUPziyMnR6Ue K7OI3Mijoi0NG4ks77xtY+yh6AE7BYWXiAoJmh0uBSArVRTNFBZF46dmtyGzxGAdXrvA uvIHNoL7M3hOUpInB7NNj8cmoPzpg0YjHxvvgab7SOG5MDCY850dCXHUE0hqOYH+7j1P WC5TqoPwa9WoRRFn5FqlOVkTq9AXPh3brqRUhbw+7EltuTAWt1duDWeIgagqi2PJlvIu sKxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JPw2Po3K5j1KcfJ68+mIpcS7q1fw1SYnoLWr5LV7uxE=; b=J5vimYKKX0YgKGoeMHdyycw/WlhlV0xn002p5GBAMpqygN214114ksxv2M28+78aOL JL7ZdYr+BLZktb2zogUveZEtdSPl8kouSELLTf+xWruJIv+e6sqsFzuyUx/OE5NxMwXX janxB+I0w9M7FYO4NSJ4IlGmBgV8bTFOTqb0vI/JUnBWlKbITtaDJc1zzNiIh9mYf6qM BSUm7cjezTEKCz3HW8GorriyloXZuo3CAGPoc2P3ezWuL3VJGHFhoUBqqDqa4zv1b9pP IPyZrKpOBvrbGdZbbILAzz7PDVdm1f+hoQS/tceiy+1u+p9PMr+39ULA6HW5mTMpz7+d w+Qw== X-Gm-Message-State: AOAM533SUxxZBdt1WcgcHBZId9pyG2t8G2m5NeFKcLYD3D0yTIKw8jPl ML3bkjMBYnZ2XCEJAI9FC4s= X-Google-Smtp-Source: ABdhPJy+nhBeOlyRoHtHZnhZhE2p3nN8WimgTvnQAQtJM8Sx2zbd7uU8TqqSz4rSSFuuWUR7rgG7BA== X-Received: by 2002:a05:651c:2005:: with SMTP id s5mr649745ljo.36.1604921642882; Mon, 09 Nov 2020 03:34:02 -0800 (PST) Received: from pc636 (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id y1sm1735911lfh.149.2020.11.09.03.34.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Nov 2020 03:34:02 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 9 Nov 2020 12:33:59 +0100 To: Andrew Morton , Minchan Kim Cc: linux-kernel@vger.kernel.org, linux-mm , "Aneesh Kumar K . V" , Harish Sriram , stable@vger.kernel.org Subject: Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range" Message-ID: <20201109113359.GA32670@pc636> References: <20201105170249.387069-1-minchan@kernel.org> <20201106175933.90e4c8851010c9ce4dd732b6@linux-foundation.org> <20201107083939.GA1633068@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201107083939.GA1633068@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote: > Hi Andrew, > > On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote: > > On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote: > > > > > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e. > > > > > > While I was doing zram testing, I found sometimes decompression failed > > > since the compression buffer was corrupted. With investigation, > > > I found below commit calls cond_resched unconditionally so it could > > > make a problem in atomic context if the task is reschedule. > > > > > > Revert the original commit for now. > > > > > > [ 55.109012] BUG: sleeping function called from invalid context at mm/vmalloc.c:108 > > > [ 55.110774] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 946, name: memhog > > > [ 55.111973] 3 locks held by memhog/946: > > > [ 55.112807] #0: ffff9d01d4b193e8 (&mm->mmap_lock#2){++++}-{4:4}, at: __mm_populate+0x103/0x160 > > > [ 55.114151] #1: ffffffffa3d53de0 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_slowpath.constprop.0+0xa98/0x1160 > > > [ 55.115848] #2: ffff9d01d56b8110 (&zspage->lock){.+.+}-{3:3}, at: zs_map_object+0x8e/0x1f0 > > > [ 55.118947] CPU: 0 PID: 946 Comm: memhog Not tainted 5.9.3-00011-gc5bfc0287345-dirty #316 > > > [ 55.121265] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 > > > [ 55.122540] Call Trace: > > > [ 55.122974] dump_stack+0x8b/0xb8 > > > [ 55.123588] ___might_sleep.cold+0xb6/0xc6 > > > [ 55.124328] unmap_kernel_range_noflush+0x2eb/0x350 > > > [ 55.125198] unmap_kernel_range+0x14/0x30 > > > [ 55.125920] zs_unmap_object+0xd5/0xe0 > > > [ 55.126604] zram_bvec_rw.isra.0+0x38c/0x8e0 > > > [ 55.127462] zram_rw_page+0x90/0x101 > > > [ 55.128199] bdev_write_page+0x92/0xe0 > > > [ 55.128957] ? swap_slot_free_notify+0xb0/0xb0 > > > [ 55.129841] __swap_writepage+0x94/0x4a0 > > > [ 55.130636] ? do_raw_spin_unlock+0x4b/0xa0 > > > [ 55.131462] ? _raw_spin_unlock+0x1f/0x30 > > > [ 55.132261] ? page_swapcount+0x6c/0x90 > > > [ 55.133038] pageout+0xe3/0x3a0 > > > [ 55.133702] shrink_page_list+0xb94/0xd60 > > > [ 55.134626] shrink_inactive_list+0x158/0x460 > > > > > > ... > > > > > > --- a/mm/vmalloc.c > > > +++ b/mm/vmalloc.c > > > @@ -102,8 +102,6 @@ static void vunmap_pmd_range(pud_t *pud, unsigned long addr, unsigned long end, > > > if (pmd_none_or_clear_bad(pmd)) > > > continue; > > > vunmap_pte_range(pmd, addr, next, mask); > > > - > > > - cond_resched(); > > > } while (pmd++, addr = next, addr != end); > > > } > > > > If this is triggering a warning then why isn't the might_sleep() in > > remove_vm_area() also triggering? > > I don't understand what specific callpath you are talking but if > it's clearly called in atomic context, the reason would be config > combination I met. > > CONFIG_PREEMPT_VOLUNTARY + no CONFIG_DEBUG_ATOMIC_SLEEP > > It makes preempt_count logic void so might_sleep warning will not work. > > > > > Sigh. I also cannot remember why these vfree() functions have to be so > > awkward. The mutex_trylock(&vmap_purge_lock) isn't permitted in > > interrupt context because mutex_trylock() is stupid, but what was the > > issue with non-interrupt atomic code? > > > > Seems like a latency issue. > > commit f9e09977671b > Author: Christoph Hellwig > Date: Mon Dec 12 16:44:23 2016 -0800 > > mm: turn vmap_purge_lock into a mutex > > The purge_lock spinlock causes high latencies with non RT kernel, > __purge_vmap_area_lazy() is our bottleneck. The list of areas to be drained can be quite big, so the process itself is time consuming. That is why it is protected by the mutex instead of spinlock. Latency issues. I proposed to optimize it here: https://lkml.org/lkml/2020/9/7/815 I will send out the patch soon, but it is another topic not related to this issue. -- Vlad Rezki