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 E420AC25B4F for ; Tue, 7 May 2024 18:08:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 775E66B0099; Tue, 7 May 2024 14:08:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7260E6B009A; Tue, 7 May 2024 14:08:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EDEF6B009B; Tue, 7 May 2024 14:08:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3526A6B0099 for ; Tue, 7 May 2024 14:08:51 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D4838A1A40 for ; Tue, 7 May 2024 18:08:50 +0000 (UTC) X-FDA: 82092385620.24.F7914F8 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf20.hostedemail.com (Postfix) with ESMTP id D23751C001B for ; Tue, 7 May 2024 18:08:48 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RHVTqkId; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=axelrasmussen@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715105329; h=from:from:sender: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:dkim-signature; bh=XSD4Y0wwauuEygpT3nwe+oQyvRjWt3XYsYKblcPp7m4=; b=32KRskCn7c56KpJpKWDfyPP8ZE9eQt6XLwQeWam1AEgMTfVtpv9nIRhT/JUS5XpwCr2Ibd faOY7ssKBRPSGkkFN70v4hIdIpfXGI08AHCd8Kzx319qIm6oKkq5dtICd8gUEGKEFJ9OZB lgkRdjzhun64SW6XaCki8biL0F8nnhE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715105329; a=rsa-sha256; cv=none; b=bc925GqARXekVUr/5MCGmcF5umWlyqdGOdmbK5Bqd6LMden4hfJqc6Djb+LojIKjrYjQOx wZU/p6ZrHg0hi2aU6RAj2XTsTt1s7Mf6LCNdvOaXNP4xfDmDUWia8uzkV/L7WFfo45w7YW HujhqD6JzxpIj+S9Dq9MpjiY6xP4ZEE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RHVTqkId; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=axelrasmussen@google.com Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2e3fa13f018so11732971fa.3 for ; Tue, 07 May 2024 11:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1715105327; x=1715710127; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XSD4Y0wwauuEygpT3nwe+oQyvRjWt3XYsYKblcPp7m4=; b=RHVTqkIdw1hRJv+M7zbNnXRS6QL0zwJqHbNsO9UPynPYSfG+QwbhLZNSATqdeg4y8T P5myBFHxKKTzMEw4duVLV54QhixzaeF14ZsQabWvGcjPDNshhFgdsTznq9NjqAHekEy+ /Wtl1WSD4DhftmyOeitFRYHlUKWg8PaosZzjABOu5GUTflwJLFbHYA0JSfGkxgXD8YBc nmuII/GY1cLerDkMtA5q5X8DPqQN9btaLkx1yGUf+zVwXLiEvKXZE/Jzit0rI5uPRoAF r4hw4ENi8MOcZbJU1Qc6YZbKsKElgdL8FA841HhUnLbzcwDjbe09fEMtU/L9qKFq1AOE Vy1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715105327; x=1715710127; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XSD4Y0wwauuEygpT3nwe+oQyvRjWt3XYsYKblcPp7m4=; b=EqpenNxufClAIEXm+oeEQOznFLi2cpOt3KI4FoL0xyZU/S2D+jzn/ots+5CfIZSrZ3 pOYVXvefVtpdhvSvoiBd0yahuqglEu7u/ObuN0z2w8vbeQ2B/oLlY9xEpEgb+s0GAByS ogPSl/cTJM9xBtDiQbK4s+m/aEBxV8X5zyQS99NNcFgJeQx5dEFBVCeCv8NLUfBJx6mg pPfRxvRv1kI7W9DeDHucQ2xwLdoDo3SnXzeA2ya5ZAFOY04+xpbPrsZpGM75/dodp6KN XlMUC8i461lkb1PYl4WxV9BCp1UvUFRn9wHlV/1TLVJj/U4eSlM51y7q15hm16ofs+7I rjIg== X-Forwarded-Encrypted: i=1; AJvYcCX64trBfOAgusEPI+iyKlSgonE6SogYCn3l4a0uGvbuLe6bPsYVQnZMsMHqaj2LuiMCnFEfHE/a1Ugb0hEyOg34Gz4= X-Gm-Message-State: AOJu0YyUrP1UgSHJfe1mXNx85QpBedpNONyEeQ9t3d4QCy8YFNroAcuU 4lpw5lPv+cx3H4jreR0tJC/fpxIswCz5DKOZRK2dzDFnFqOFAfIMH/OSmeM5VufcSNYODWHfpdI PKZJ9y8Qx3U8WGTiNs5PUACpEvjXUZJHAOUUl X-Google-Smtp-Source: AGHT+IFt0R7BfebKvG+JJRTdFCiGDS50YFGKplqdUY2j9QyIWURq8EJbZJ+S/o4OKvOffwGI4qWO0S/hem+M+0wMsk0= X-Received: by 2002:a2e:9d91:0:b0:2e0:ffea:4298 with SMTP id 38308e7fff4ca-2e4475a1987mr2510301fa.34.1715105326873; Tue, 07 May 2024 11:08:46 -0700 (PDT) MIME-Version: 1.0 References: <20240507022939.236896-1-jhubbard@nvidia.com> <016d8cff-efc3-4ef1-9aff-7c21c48f2d69@redhat.com> <302d50ac-45ff-470e-90a0-b349821706a6@nvidia.com> <21d88422-7378-4a63-8fbf-f70889f309c1@redhat.com> In-Reply-To: <21d88422-7378-4a63-8fbf-f70889f309c1@redhat.com> From: Axel Rasmussen Date: Tue, 7 May 2024 11:08:07 -0700 Message-ID: Subject: Re: [PATCH] x86/fault: speed up uffd-unit-test by 10x: rate-limit "MCE: Killing" logs To: David Hildenbrand Cc: John Hubbard , Andy Lutomirski , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , LKML , linux-mm@kvack.org, Peter Xu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D23751C001B X-Stat-Signature: cgrqe9gbg4kszddifeb738t53wuktin8 X-Rspam-User: X-HE-Tag: 1715105328-67230 X-HE-Meta: U2FsdGVkX18YQbKcUzuwyoN3ceZv55BtqRmbdDKhvq4Wbq3+slWgpL7Wjpdx7Uy0VcgrfcpAx/NtWLc9jwAbjSpZWu7L8QvgtxERU9clMgEw8cW8LNSWlQOqjLLMe49J18vCpO3lIWQncg9Gb4SVdq1yeWOEU6y4jnbrIixUQ0WIsTnF1LOO7GuAi1AIwbfrHCuLg3p2gca782GBTzvCS7QBa5WGmP1zhdL45648hY42OSk7TeKu6CRlISMlwxkZ9Ec0nLGq2LmBk0mdJgVmynW4mlreW8avFRGS/uc9kZtsZX7UP5GLw3mFyDIzqhOg3SRNPIsMK48wTrcYqHNab2ueLxtG9shvuR0lhnWchOFquW3OJvIUQjv3V4CBFfAaigb9skqa+prQzJ0EidxS7MOzFQjHaDpBbCb8YjyMZKrCZbCYrkQ3cdPX/K4grOOZYKJzZrlJNDh0qwq8uHqOaMMAQ2zy6a3BcNza787E6qCYXiLh0w7TnopxtwO2oCJ+cre9L6yIuFLKM9ptwDshpw8Ja9kTiyByW7yhlFW2vmMGxw52Bq+oK11ToRzv2A1FLGI5ZCGkYAql4SHX05T50mIqDPj934kps6XI5ImjUmZkuzbujdxPacglTVCMxOL8hw7NvMfXUc5GYYZKYQpT0kGFywFqAW5U1HDQmYhKWk22CXbjWv9RW/dp16XXCFT4uGFAntUgb0KxEs+pFKR2Ea6z87cSUX6M2TNFC79acTfvs4q/ZXa5Im5Gfe8YW3tw0aGq+Q+PXk/2FMEwxzrsJj6Rm7kA4iIj8iR6z0NUZ0loICy5Jv3cS8hN8/GCTwJBelDmcXbuaGldfslp4ZS4qJqvF0qVI768aet7Xj+h4dMp3R9Onz+yMm2PNEAEYTPSKrfli6cifmeHBI7Sbg4IkDdy5i4rUK65SwwI5BJ0VOwizZZx5XCfUkVYLLZgE6kfGM/IXLFUI1gFp0TT3iT o2MgkEur yp9OV5rNR8pTf3eu87Bp+T3mZAGRqJm5mFTuFDjbX13syS/huFU3pDE9RCWWH9Evxbqjshp/0ct3dQGNC49iLwifajnGykp3J04xYPmC1GpyqFCOWaWEbyAqH4en63UE3Ik07XibX93AtiTdOQeScJ3cicyiABDAlHdE0237oXJ+9f/2HUwUqRfv6+GtjUq/WeksF22hT3YLQv+FKjDUrkbB/2EEem/WzSqd5xMvzddhJ1jvDIcSNtg6R/my/okIGVDEd26zrwtynK92kuYe+4wtbyr7v4j63Ov8EBfik11qrgNk5vlzET9At5Ic5NvIWanM81rZY0L+O5rY= 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: List-Subscribe: List-Unsubscribe: On Tue, May 7, 2024 at 9:43=E2=80=AFAM David Hildenbrand = wrote: > > On 07.05.24 18:28, John Hubbard wrote: > > On 5/7/24 1:13 AM, David Hildenbrand wrote: > >> The patch subject is misleading. This should be "don't flood the syste= m > > > > I went back and forth on that subject line. :) > > > >> log". Nobody cares about the speed of a unittest ;) > > > > Yes they do. People should actually run the selftests, which in turn ha= ve > > enshrined their guidelines in kernel doc. See dev-tools/kselftest.rst, > > "Contributing new tests", which says, as you would hope, "Don't take > > too long". > > > > It's important. Tests need to be quick, and having one out of 50 that > > blows it up is worth fixing. > > I'm pretty sure you got my point: it's much more important to not let > unprivileged users flood the log (possibly harming the system?) than > making a test run faster :) > > > > >> > >> On 07.05.24 04:29, John Hubbard wrote: > >>> If a system experiences a lot of memory failures, then any associated > >>> printk() output really needs to be rate-limited. I noticed this while > >>> running selftests/mm/uffd-unit-tests, which logs 12,305 lines of outp= ut, > >>> adding (on my system) an extra 97 seconds of runtime due to printk ti= me. > >> > >> Recently discussed: > >> > >> https://lkml.kernel.org/r/a9e3120d-8b79-4435-b113-ceb20aa45ee2@alu.uni= zg.hr > >> > >> See the pros/cons of using ratelimiting, and what an alternative for > >> uffd is that Axel is working on. > >> > >> (CCing Peter and Axel) > >> > > > > That thread seems to have stalled. > > Yes, there was no follow-up. Apologies, I had completely forgotten about this. I blame the weekend. :) No objections from me to the simple rate limiting proposed here, if useful you can take: Acked-by: Axel Rasmussen But, it seems to me the earlier proposal may still be useful. Specifically, don't print at all for "synthetic" poisons from UFFDIO_POISON or similar mechanisms. This way, "real" errors aren't gobbled up by the ratelimit due to spam from "synthetic" errors. If folks agree, I can *actually* send a patch this time. :) > > > I *do* have MCE experience (writing a > > handler, > > dealing with MCEs and related bugs), and what they wrote so far is exac= tly > > correct: if you were going to flood the log, then no, we don't need to = see > > every single line printed. The first 10 or so, plus the fact that rate > > limiting > > kicked in, is sufficient to proceed with debugging and/or hardware > > replacement. > > > > I'd like to just do this patch almost as-is, just with a fixed up subje= ct, > > perhaps: > > > > x86/fault: rate-limit to avoid flooding dmesg with "MCE: Killing" > > reports > > > > Yes? > > > Makes sense to me (and thanks for confirming that we don't need > complexity elsewhere). > > I think we at least need "Fixes:" (not sure if stable is warranted as > well, 1b0a151c10a6d823f033023b9fdd9af72a89591b didn't CC stable). > > Consider adding a link to the report in that thread. > > Acked-by: David Hildenbrand > > -- > Cheers, > > David / dhildenb >