From: Borislav Petkov <bp@alien8.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Jia He <justin.he@arm.com>, Len Brown <lenb@kernel.org>,
Tony Luck <tony.luck@intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Robert Richter <rric@kernel.org>,
Robert Moore <robert.moore@intel.com>,
Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
Yazen Ghannam <yazen.ghannam@amd.com>,
Jan Luebbe <jlu@pengutronix.de>,
Khuong Dinh <khuong@os.amperecomputing.com>,
Kani Toshi <toshi.kani@hpe.com>,
James Morse <james.morse@arm.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-edac@vger.kernel.org, devel@acpica.org,
"Rafael J . Wysocki" <rafael@kernel.org>,
Shuai Xue <xueshuai@linux.alibaba.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
linux-efi@vger.kernel.org, nd@arm.com,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v10 6/7] apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Date: Sat, 22 Oct 2022 12:00:32 +0200 [thread overview]
Message-ID: <Y1O/QN32d2AlzEiA@zn.tnic> (raw)
In-Reply-To: <CAMj1kXFu36faTPoGSGPs9KhcKsoh_DE9X2rmwdenxaJwa3P_yw@mail.gmail.com>
On Sat, Oct 22, 2022 at 11:01:01AM +0200, Ard Biesheuvel wrote:
> But the point is that the new element we are adding has the same
> properties as the one we want to avoid replacing inadvertently,
No, we're removing the oldest element we found. The new one is anything
but we don't compare it to slot_cache which we're about to remove.
> and if the cmpxchg() failed, we just drop it on the floor.
Yeah, I guess the intent here was: oh well, we'll log that thing again
because our "throttling cache" didn't manage to enter it.
> So instead of dropping 'our' new element, we now drop 'the other' new
> element.
Aha, this is what you mean with logging something twice. That other new
element gets dropped so if it happens again, it'll get logged and if it
then gets entered in the cache properly, then it gets ignored on the
next logging run.
Oh well, fine with me.
> The correct approach here would be to rerun the selection loop on
> failure, but I doubt whether it is worth it. This is just a fancy rate
> limiter.
Yap, exactly.
Ok, so I'll try to summarize what we talked here in the commit message
so that it is written down somewhere for later.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2022-10-22 10:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 8:22 [PATCH v10 0/7] Make ghes_edac a proper module Jia He
2022-10-18 8:22 ` [PATCH v10 1/7] efi/cper: export several helpers for ghes_edac to use Jia He
2022-10-18 8:22 ` [PATCH v10 2/7] EDAC/ghes: Add a notifier for reporting memory errors Jia He
2022-10-18 8:22 ` [PATCH v10 3/7] EDAC/ghes: Prepare to make ghes_edac a proper module Jia He
2022-10-18 8:22 ` [PATCH v10 4/7] EDAC/ghes: Make ghes_edac a proper module to remove the dependency on ghes Jia He
2022-10-18 8:22 ` [PATCH v10 5/7] EDAC: Add the ghes_get_devices() check for chipset-specific edac drivers Jia He
2022-10-18 8:22 ` [PATCH v10 6/7] apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg() Jia He
2022-10-22 8:43 ` Borislav Petkov
2022-10-22 9:01 ` Ard Biesheuvel
2022-10-22 10:00 ` Borislav Petkov [this message]
2022-10-24 15:43 ` [PATCH] " Borislav Petkov
2022-10-25 8:48 ` Ard Biesheuvel
2022-10-25 18:28 ` Rafael J. Wysocki
2022-10-25 18:38 ` Borislav Petkov
2022-10-18 8:22 ` [PATCH v10 7/7] EDAC/igen6: Return consistent errno when another edac driver is enabled Jia He
2022-10-25 14:08 ` [PATCH v10 0/7] Make ghes_edac a proper module Borislav Petkov
2022-10-26 1:06 ` Justin He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1O/QN32d2AlzEiA@zn.tnic \
--to=bp@alien8.de \
--cc=ardb@kernel.org \
--cc=devel@acpica.org \
--cc=james.morse@arm.com \
--cc=jarkko@kernel.org \
--cc=jlu@pengutronix.de \
--cc=justin.he@arm.com \
--cc=khuong@os.amperecomputing.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=nd@arm.com \
--cc=peterz@infradead.org \
--cc=qiuxu.zhuo@intel.com \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=rric@kernel.org \
--cc=tony.luck@intel.com \
--cc=toshi.kani@hpe.com \
--cc=xueshuai@linux.alibaba.com \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox