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 54337C433F5 for ; Mon, 25 Apr 2022 15:16:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 782FA6B0074; Mon, 25 Apr 2022 11:16:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 731796B0075; Mon, 25 Apr 2022 11:16:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 621F26B0078; Mon, 25 Apr 2022 11:16:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 5648B6B0074 for ; Mon, 25 Apr 2022 11:16:17 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2858F21CF9 for ; Mon, 25 Apr 2022 15:16:17 +0000 (UTC) X-FDA: 79395752394.23.26F7821 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf15.hostedemail.com (Postfix) with ESMTP id 833F7A003C for ; Mon, 25 Apr 2022 15:16:12 +0000 (UTC) Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-2f7c322f770so55934827b3.20 for ; Mon, 25 Apr 2022 08:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=VgCwJNrSWLamwr26sf8FxhD/HG4cXOd5kOE1NHtb3Lc=; b=n+3K4I/06qyEIawpbSiGFoxmIG2WckzHJniuNA3IrWYHIDmrQJPps1fZCv8oZNwSmM djRwqb8qKIJdhL5flEOwoWrVf3bgw6r6rtBL6CiLjfJjgVeHt9rbRyZvi2iSQtcSgL0m 65ns45Ge3Iq2HNetZYhGnHOJBhbwo86ueRNoo7CPPkWaqJ5XyjXrA6fYqELFFEZSjet5 0OWyA1mggzBwOWq2YcP+eq1e9fceZkTFP0kFcxB7g7bqxE3NHOKo/3QkDrmhQK19CILR xTvPRmKD1wfvVAMuwJG6R7P9g1gkSn/gsfhl21Nj9xXHYQ1wxqgQ0MMJhY0uXSFekZE/ Z5QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=VgCwJNrSWLamwr26sf8FxhD/HG4cXOd5kOE1NHtb3Lc=; b=oAOXuICq5Ve4enUFT67jeecCYwhkXkSFxrRh2pPjRd2TQgKwo5xJhzkj4WENFcAieB ArMp5XfIaJtW6vryBUz+q61ZpnQWENZqAUjAVSM/Vy+RTDRkzTEH8H0urwD0HV6T43Qa 1HE+p6oxbC5AmMIdAHh/lVRDoLPtrtHUT/8h+9BIlURjm4mfNkKIN01nhGJ1yx226Kx/ AnABfK8+OvevpejxF/hzop0/P/q1Z8gBeWzHq6uHNcao4HrPRXKWTXhK7KkuKW5WDIvy dQqYAGm36CMkXyQmrUL3m66IZ1jh0jXk+I3Dq+Wz+rO3rK6nYzGcKincf18vg+0Wsk/D R5Qg== X-Gm-Message-State: AOAM532Am8ktMFpqH4Yaqto/XLIfheeiXzVWYsyG2JnNuCLDBlSJbNcX EDqY1M9wcJ+v7R1lyGqCEbWcXu5vjcp4tQ== X-Google-Smtp-Source: ABdhPJwU4K+YuD6yyf2aAdrpYnOWuj48hDCtiv+bO71qwNSDnOZ34f4eBzdf+Yw8LRMOIjCH7Y8ILNnSfkLjmA== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:28b]) (user=shakeelb job=sendgmr) by 2002:a81:a4e:0:b0:2f7:d86c:e565 with SMTP id 75-20020a810a4e000000b002f7d86ce565mr6895908ywk.374.1650899775751; Mon, 25 Apr 2022 08:16:15 -0700 (PDT) Date: Mon, 25 Apr 2022 15:16:12 +0000 In-Reply-To: Message-Id: <20220425151612.izmxhkgugq6isyz3@google.com> Mime-Version: 1.0 References: <20220421234426.3494842-1-yosryahmed@google.com> <20220421234426.3494842-5-yosryahmed@google.com> <20220423142801.gnvd42cdcsz4hpon@google.com> Subject: Re: [PATCH v4 4/4] selftests: cgroup: add a selftest for memory.reclaim From: Shakeel Butt To: Yosry Ahmed Cc: Johannes Weiner , Michal Hocko , Andrew Morton , Roman Gushchin , David Rientjes , Tejun Heo , Zefan Li , Jonathan Corbet , Shuah Khan , Yu Zhao , Dave Hansen , Wei Xu , Greg Thelen , Chen Wandun , Vaibhav Jain , "Michal =?utf-8?Q?Koutn=C3=BD?=" , Tim Chen , Dan Schatzberg , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List , Linux-MM , linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="us-ascii" X-Stat-Signature: g1a5jpt6oyp6zp5cogzgfypqf9pgo4e4 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 833F7A003C Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="n+3K4I/0"; spf=pass (imf15.hostedemail.com: domain of 3P7tmYggKCGoaPISMMTJOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--shakeelb.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3P7tmYggKCGoaPISMMTJOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--shakeelb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-HE-Tag: 1650899772-30213 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000035, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Apr 23, 2022 at 02:43:13PM -0700, Yosry Ahmed wrote: [...] > > > + cg_run_nowait(memcg, alloc_pagecache_50M_noexit, (void *)(long)fd); > > > + sleep(1); > > > > These sleep(1)s do not seem robust. Since kernel keeps the page cache > > around, you can convert anon to use tmpfs and use simple cg_run to > > trigger the allocations of anon (tmpfs) and file which will remain in > > memory even after return from cg_run. > > Other tests in the file are also using sleep approach (see > test_memcg_min, although it retries for multiple times until > memory.current reaches an expected amount). In my experience it hasn't > been flaky running for multiple times on different machines, but I > agree it can be flaky (false negative). > If other tests are doing the same then ignore this comment for now. There should be a separate effort to move towards more deterministic approach for the tests instead of sleep(). > I am not sure about the allocating file pages with cg_run, is it > guaranteed that the page cache will remain in memory until the test > ends? If it doesn't, it can also flake, but it would produce false > positives (the test could pass because the kernel drained page cache > for some other reason although the interface is not working > correctly). > > In my personal opinion, false negative flakes are better than false > positives. At least currently the test explicitly and clearly fails if > the allocations are not successful. If we rely on the page cache > remaining until the test finishes then it could silently pass if the > interface is not working correctly. > > There are a few ways we can go forward with this: > 1) Keep everything as-is, but print a message if the test fails due to > memory.current not reaching 100MB to make it clear that it didn't fail > due to a problem with the interface. > 2) Add a sleep/retry loop similar to test_memcg_min instead of sleeping once. > 3) Send a signal from forked children when they are done with the > allocation, and wait to receive this signal in the test to make sure > the allocation is completed. > > In my opinion we should do (1) (and maybe (2)) for now as (3) could be > an overkill if the test is normal passing. Maybe add a comment about > (3) being an option in the future if the test flakes. Let me know what > you think? I am ok with (1).