Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Tue, 25 Mar 2025 11:48:11 -0400
Organization: A noiseless patient Spider
Lines: 14
Message-ID: <jwviknxp0zj.fsf-monnier+comp.arch@gnu.org>
References: <vqto79$335c6$1@dont-email.me>
	<684d32898ec85b91bcb9dcdb97d8065a@www.novabbs.org>
	<vrspp6$jpn$1@reader1.panix.com> <8qyEP.1257951$FVcd.630606@fx10.iad>
	<vrugt2$lqf$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 25 Mar 2025 16:48:12 +0100 (CET)
Injection-Info: dont-email.me; posting-host="32f3952deabf3f9cd9365c937ba1cce9";
	logging-data="3750915"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+EuBg62YQMBajoPx9N2T2vGYy4LWl8dCw="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:QWUXbXGFotbYBEYLTJXZ0rL51iM=
	sha1:00fvMRCF4ed4bPhBprpDJUDSv9E=
Bytes: 1701

> a going to make a big difference here.  But I also wonder at the
> internal implementation of these instructions in e.g. that
> Fujitsu chip that allows throughput to stay more or less
> constant as the number of cores increases; I'd think that cache
> coherency traffic as threads contend for a single cache line
> would create a bottleneck leading to (at least) a linear
> slow down.

IIUC the idea is that the atomic-add is sent to the memory and performed
there, instead of moving the data to the cache.  So there's no
contention for the cache line because the data is not in a cache at all.


        Stefan