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=-9.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 7B62EC07E95 for ; Fri, 2 Jul 2021 21:00:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EF883613F5 for ; Fri, 2 Jul 2021 21:00:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF883613F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 639556B0082; Fri, 2 Jul 2021 17:00:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C2696B0083; Fri, 2 Jul 2021 17:00:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 414AF8D0005; Fri, 2 Jul 2021 17:00:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 16F8D6B0082 for ; Fri, 2 Jul 2021 17:00:14 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A99851D999 for ; Fri, 2 Jul 2021 21:00:13 +0000 (UTC) X-FDA: 78318865506.29.39C867E Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by imf21.hostedemail.com (Postfix) with ESMTP id 6092AD008798 for ; Fri, 2 Jul 2021 21:00:13 +0000 (UTC) Received: by mail-io1-f47.google.com with SMTP id i189so13198158ioa.8 for ; Fri, 02 Jul 2021 14:00:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=eJiGAN6TDR6lmwiAYmh3I6OaAmocOou8J1w1pSB9/H0=; b=h0fOHzOC5zjCrNsK5z4QuaEq1vSqixovrw2/t1SaUsweaxBeMznMjYTtaxw4oH1uhv 7sb0fgf1V/JRCFEcvzeB24Au1MlHPPFgkicMcM2cZH7i62VY6ssCrDMAHen4aGVaaI8k QgXhNmifB92u979i4NEKt5LQfPsRHWuQkmxWxRfHgdShNfNVpiKu01DZqqpwmYSU5jJI 8SK4JC5dqF/z3zgOZz6d8bnMze+nv+vAmq5xpoSiIzxFTqRNlnhI6NdwfLxOX66sv/oH NANeJgInO0KkdbhBVSpS8Lic+linTj59E0UzHTSfOC60xbQ60atU5BEwcagqIx6RL+IW g6nQ== X-Gm-Message-State: AOAM532VBlRMjfo4fEt6ARJy2ZLVI9k6L/jvm+sKY2d4hhl0tZG+FEoM ZI/I2qAn+1l8cMLK8Te+swg= X-Google-Smtp-Source: ABdhPJyHMRv1obezn+AfX6bOyzQG76tl7I6rKmaqgrj+MqxqdnHnoP4BX96FwzKWiO449bdx4Qvc6Q== X-Received: by 2002:a5d:9c86:: with SMTP id p6mr1445235iop.24.1625259612732; Fri, 02 Jul 2021 14:00:12 -0700 (PDT) Received: from google.com (243.199.238.35.bc.googleusercontent.com. [35.238.199.243]) by smtp.gmail.com with ESMTPSA id o7sm2331377ilt.29.2021.07.02.14.00.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jul 2021 14:00:12 -0700 (PDT) Date: Fri, 2 Jul 2021 21:00:11 +0000 From: Dennis Zhou To: Guenter Roeck Cc: Tejun Heo , Christoph Lameter , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] percpu: implement partial chunk depopulation Message-ID: References: <20210419225047.3415425-1-dennis@kernel.org> <20210419225047.3415425-4-dennis@kernel.org> <20210702191140.GA3166599@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of dennisszhou@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=dennisszhou@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) X-Stat-Signature: 3xx517xnf71698bh7c9ejmd6yedspbup X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6092AD008798 X-HE-Tag: 1625259613-936198 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 Fri, Jul 02, 2021 at 01:28:18PM -0700, Guenter Roeck wrote: > On 7/2/21 12:45 PM, Dennis Zhou wrote: > > Hello, > > > > On Fri, Jul 02, 2021 at 12:11:40PM -0700, Guenter Roeck wrote: > > > Hi, > > > > > > On Mon, Apr 19, 2021 at 10:50:46PM +0000, Dennis Zhou wrote: > > > > From: Roman Gushchin > > > > > > > > This patch implements partial depopulation of percpu chunks. > > > > > > > > As of now, a chunk can be depopulated only as a part of the final > > > > destruction, if there are no more outstanding allocations. However > > > > to minimize a memory waste it might be useful to depopulate a > > > > partially filed chunk, if a small number of outstanding allocations > > > > prevents the chunk from being fully reclaimed. > > > > > > > > This patch implements the following depopulation process: it scans > > > > over the chunk pages, looks for a range of empty and populated pages > > > > and performs the depopulation. To avoid races with new allocations, > > > > the chunk is previously isolated. After the depopulation the chunk is > > > > sidelined to a special list or freed. New allocations prefer using > > > > active chunks to sidelined chunks. If a sidelined chunk is used, it is > > > > reintegrated to the active lists. > > > > > > > > The depopulation is scheduled on the free path if the chunk is all of > > > > the following: > > > > 1) has more than 1/4 of total pages free and populated > > > > 2) the system has enough free percpu pages aside of this chunk > > > > 3) isn't the reserved chunk > > > > 4) isn't the first chunk > > > > If it's already depopulated but got free populated pages, it's a good > > > > target too. The chunk is moved to a special slot, > > > > pcpu_to_depopulate_slot, chunk->isolated is set, and the balance work > > > > item is scheduled. On isolation, these pages are removed from the > > > > pcpu_nr_empty_pop_pages. It is constantly replaced to the > > > > to_depopulate_slot when it meets these qualifications. > > > > > > > > pcpu_reclaim_populated() iterates over the to_depopulate_slot until it > > > > becomes empty. The depopulation is performed in the reverse direction to > > > > keep populated pages close to the beginning. Depopulated chunks are > > > > sidelined to preferentially avoid them for new allocations. When no > > > > active chunk can suffice a new allocation, sidelined chunks are first > > > > checked before creating a new chunk. > > > > > > > > Signed-off-by: Roman Gushchin > > > > Co-developed-by: Dennis Zhou > > > > Signed-off-by: Dennis Zhou > > > > > > This patch results in a number of crashes and other odd behavior > > > when trying to boot mips images from Megasas controllers in qemu. > > > Sometimes the boot stalls, but I also see various crashes. > > > Some examples and bisect logs are attached. > > > > Ah, this doesn't look good.. Do you have a reproducer I could use to > > debug this? > > > > I copied the relevant information to http://server.roeck-us.net/qemu/mips/. > This is perfect! I'm able to reproduce it. > run.sh - qemu command (I tried with qemu 6.0 and 4.2.1) > rootfs.ext2 - root file system > config - complete configuration > defconfig - shortened configuration > vmlinux - a crashing kernel image (v5.13-7637-g3dbdb38e2869, with above configuration) > > Interestingly, the crash doesn't always happen at the same location, even > with the same image. Some memory corruption, maybe ? > Well a few factors matter, percpu gets placed in random places. Percpu allocations may happen in different order and this will cause different freeing patterns. Then the problem patch may free the wrong backing page. I'm working on it, x86 doesn't seem to have any immediate issues (fingers crossed) so it must be some delta here. > Hope this helps. Please let me know if I can provide anything else. > > Thanks, > Guenter Thanks, Dennis