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=-8.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 0748DC433F5 for ; Fri, 3 Sep 2021 09:31:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9677E60F91 for ; Fri, 3 Sep 2021 09:31:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9677E60F91 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C50998D0002; Fri, 3 Sep 2021 05:31:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD8EA8D0001; Fri, 3 Sep 2021 05:31:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7A438D0002; Fri, 3 Sep 2021 05:31:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id 955E38D0001 for ; Fri, 3 Sep 2021 05:31:07 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 43CD418379397 for ; Fri, 3 Sep 2021 09:31:07 +0000 (UTC) X-FDA: 78545743374.08.98BEB6E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf04.hostedemail.com (Postfix) with ESMTP id C17CE50000A4 for ; Fri, 3 Sep 2021 09:31:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630661466; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N5+N+U9+Ro03PZVc42PFsHKY2Zftj9SLOC7/mSkA8LA=; b=HHcmkmvnHPS6DZgLpOUEW2Cfy6rJt6VT6APWSZ72jQDKesTfZZsdKRzJEFuDw/GgkxRnBO /Q2XijtDgQdkW0ZojxYept2Lmmf1S8CM6VhthWawTmu1ea+5RFZXQ2+mVn0egrkicFfMKV E291bPDyT2FZyyRoN0DWWsiXg+XB4q8= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-13-QbhL9-iPNQGFQkFX7HB6IQ-1; Fri, 03 Sep 2021 05:31:04 -0400 X-MC-Unique: QbhL9-iPNQGFQkFX7HB6IQ-1 Received: by mail-wm1-f70.google.com with SMTP id m22-20020a7bcb96000000b002f7b840d9dcso1692798wmi.1 for ; Fri, 03 Sep 2021 02:31:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=N5+N+U9+Ro03PZVc42PFsHKY2Zftj9SLOC7/mSkA8LA=; b=UzlWK+yikEfiLWozB4lds7r0H5QkbwvRPEuqpNglexkx3l6hpqEK5/fcRa/AuDncrJ u2Ln2bYJIFrZ/Gp9mgN7k5riMUgEC61ZmlQ5Lj69nITXFG0t43zehLRHKxH/tHQj+YyN t6IuLl3vhj4Ezbyjl12oSXNWFRzHYirlAAdNiuNj6A67qPDkA9QztK8YEBtUheeMwacR 4CxlEobjm3sru3CSt4pFbyEeY3oxgowOhMX51ZHfIbWT2AHbobfVLHdsf9UFVLZ8taKC zB4PF+NB1BQ219hG59Ubsq/FH2ReOthKMMpd0pUZKk03qEImk5+RyGo+oRMhquDYdLaD 43ZA== X-Gm-Message-State: AOAM531LrRgALTutxt4ee8YgzNpj3CoYGfpyqG0lJDwHgGHrVB+VULxR QK8jFz/iJvP/5qjXauI63EtvDdgeCPzRNj3uu5yklxkmPNgZlWa/FKmVi1a6GGlxcCkF2SdmsFR l9jn4u1t6YBg= X-Received: by 2002:adf:c54f:: with SMTP id s15mr2953088wrf.222.1630661462964; Fri, 03 Sep 2021 02:31:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5o7mCUSKHnT4zBk3DaC9uUSt8QVVTDjXAr1RDTVgACfhSL4WqgOPMh3i3zQ432rXMqQciww== X-Received: by 2002:adf:c54f:: with SMTP id s15mr2953059wrf.222.1630661462706; Fri, 03 Sep 2021 02:31:02 -0700 (PDT) Received: from [192.168.3.132] (p4ff23e05.dip0.t-ipconnect.de. [79.242.62.5]) by smtp.gmail.com with ESMTPSA id n18sm3653838wmc.22.2021.09.03.02.31.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Sep 2021 02:31:02 -0700 (PDT) Subject: Re: [RFC][PATCH] mm/page_isolation: tracing: trace all test_pages_isolated failures To: "George G. Davis" Cc: Andrew Morton , "open list:MEMORY MANAGEMENT" , open list , Eugeniu Rosca , "George G. Davis" References: <20210823202823.13765-1-george_davis@mentor.com> <4f680b5a-9076-3ba4-caea-bdd6eafeb899@redhat.com> <20210902222152.GA25844@mam-gdavis-dt> From: David Hildenbrand Organization: Red Hat Message-ID: <8dca5a34-2c5c-bc49-b2ad-f3e5e0fdbba3@redhat.com> Date: Fri, 3 Sep 2021 11:31:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210902222152.GA25844@mam-gdavis-dt> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HHcmkmvn; spf=none (imf04.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C17CE50000A4 X-Stat-Signature: mi7nf168f1ef1kk6g5s8hg456b586qp4 X-HE-Tag: 1630661466-630796 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 03.09.21 00:21, George G. Davis wrote: > On Tue, Aug 31, 2021 at 04:53:31PM +0200, David Hildenbrand wrote: >> On 23.08.21 22:28, George G. Davis wrote: >>> From: "George G. Davis" >>> >>> Some test_pages_isolated failure conditions don't include trace points. >>> For debugging issues caused by "pinned" pages, make sure to trace all >>> calls whether they succeed or fail. In this case, a failure case did not >>> result in a trace point. So add the missing failure case in >>> test_pages_isolated traces. >> >> In which setups did you actually run into these cases? > > Good question! > > Although I'm not 100% certain that this specific failure condition has > occurred in my recent testing, I'm able to reproduce cma_alloc -EBUSY > faiure conditions when testing latest/recent master on arm64 based > Renesas R-Car Starter Kit [1] using defconfig with > CONFIG_CMA_SIZE_MBYTES=384 while running the following test case: Okay, I think you are not hitting the path you touched in this patch, because I assume it will never ever really trigger ... > > trace-cmd record -N 192.168.1.87:12345 -b 4096 -e cma -e page_isolation -e compaction -e migrate & > sleep 10 > while true; do a=$(( ( RANDOM % 10000 ) + 1 )); echo $a > /sys/kernel/debug/cma/cma-reserved/alloc && (usleep $a; echo $a > /sys/kernel/debug/cma/cma-reserved/free); done & > while true; do b=$(( ( RANDOM % 10000 ) + 1 )); echo $b > /sys/kernel/debug/cma/cma-reserved/alloc && (usleep $b; echo $b > /sys/kernel/debug/cma/cma-reserved/free); done & > while true; do c=$(( ( RANDOM % 10000 ) + 1 )); echo $c > /sys/kernel/debug/cma/cma-reserved/alloc && (usleep $c; echo $c > /sys/kernel/debug/cma/cma-reserved/free); done & > while true; do d=$(( ( RANDOM % 10000 ) + 1 )); echo $d > /sys/kernel/debug/cma/cma-reserved/alloc && (usleep $d; echo $d > /sys/kernel/debug/cma/cma-reserved/free); done & > while true; do e=$(( ( RANDOM % 10000 ) + 1 )); echo $e > /sys/kernel/debug/cma/cma-reserved/alloc && (usleep $e; echo $e > /sys/kernel/debug/cma/cma-reserved/free); done & > /selftests/vm/transhuge-stress & > > The cma_alloc -EBUSY failures are caused by THP compound pages allocated > from the CMA region where migration does not seem to work for compound > THP pages. The work around is to disable CONFIG_TRANSPARENT_HUGEPAGE > since it seems incompatible with the intended use of the CMA region. Oh, that sounds broken, THP should not block CMA allocation or page migration for other purposes. a) Are these temporary or permanent allocation errors? If they are permanent, they will also break memory unplug. b) Did you reproduce on other architectures as well? c) Did it use to work but is now broken? IOW, did you try bisecting? -- Thanks, David / dhildenb