Re: Another security vulnerability

Liste des GroupesRevenir à c arch 
Sujet : Re: Another security vulnerability
De : paaronclayton (at) *nospam* gmail.com (Paul A. Clayton)
Groupes : comp.arch
Date : 29. Mar 2024, 02:51:51
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <uu56rq$3u2ve$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0
On 3/28/24 3:59 PM, MitchAlsup1 wrote:
EricP wrote:
[snip]
(d) any new pointers are virtual address that have to start back at
     the Load Store Queue for VA translation and forwarding testing
     after applying (a),(b) and (c) above.
 This is the tidbit that prevents doing prefetches at/in the DRAM controller.
The address so fetched needs translation !! And this requires dragging
stuff over to DRC that is not normally done.
With multiple memory channels having independent memory
controllers (a reasonable design I suspect), a memory controller
may have to send the prefetch request to another memory controller
anyway. If the prefetch has to take a trip on the on-chip network,
a "minor side trip" for translation might not be horrible (though
it seems distasteful to me).
With the Mill having translation at last level cache miss, such
prefetching may be more natural *but* distributing the virtual
address translations and the memory controllers seems challenging
when one wants to minimize hops.
[snip]
BUT, as PIUMA proposes, we also allow the memory subsystem to read and write
individual aligned 8-byte values from DRAM, rather than whole cache lines,
so we only move that actual 8 bytes values we need.
 Busses on cores are reaching the stage where an entire cache line
is transferred in 1-cycle. With such busses, why define anything smaller than a cache line ?? {other than uncacheable accesses}
The Intel research chip was special-purpose targeting cache-unfriendly code. Reading 64 bytes when 99% of the time 56 bytes would be unused is rather wasteful (and having more memory channels helps under high thread count).
However, even for a "general purpose" processor, "word"-granular
atomic operations could justify not having all data transfers be
cache line size. (Such are rare compared with cache line loads
from memory or other caches, but a design might have narrower
connections for coherence, interrupts, etc. that could be used for
small data communication.)
In-cache compression might also nudge the tradeoffs. Being able to
have higher effective bandwidth when data is transmitted in a
compressed form might be useful. "Lossy compression", where the
recipient does not care about much of the data, would allow
compression even when the data itself is not compressible. For
contiguous useful data, this is comparable to a smaller cache
line.

Date Sujet#  Auteur
24 Mar 24 * Another security vulnerability58Stephen Fuld
24 Mar 24 +* Re: Another security vulnerability4MitchAlsup1
25 Mar 24 i+* Re: Another security vulnerability2Stefan Monnier
26 Mar 24 ii`- Re: Another security vulnerability1Michael S
26 Mar 24 i`- Re: Another security vulnerability1Michael S
24 Mar 24 +* Re: Another security vulnerability10Lawrence D'Oliveiro
25 Mar 24 i+- Re: Another security vulnerability1Stefan Monnier
25 Mar 24 i`* Re: Another security vulnerability8Stephen Fuld
25 Mar 24 i `* Re: Another security vulnerability7Lawrence D'Oliveiro
26 Mar 24 i  +* Re: Another security vulnerability5MitchAlsup1
26 Mar 24 i  i`* Re: Another security vulnerability4Lawrence D'Oliveiro
27 Mar 24 i  i `* Re: Another security vulnerability3Stephen Fuld
28 Mar 24 i  i  `* Re: Another security vulnerability2Lawrence D'Oliveiro
28 Mar 24 i  i   `- Re: Another security vulnerability1MitchAlsup1
26 Mar 24 i  `- Re: Another security vulnerability1Michael S
25 Mar 24 +* Re: Another security vulnerability18Thomas Koenig
25 Mar 24 i+* Re: Another security vulnerability16Anton Ertl
26 Mar 24 ii+* Re: Another security vulnerability13Lawrence D'Oliveiro
26 Mar 24 iii`* Re: Another security vulnerability12Anton Ertl
5 Jun 24 iii `* Re: Another security vulnerability11MitchAlsup1
5 Jun 24 iii  +* Re: Another security vulnerability9Anton Ertl
11 Jun 24 iii  i`* Re: Another security vulnerability8MitchAlsup1
11 Jun 24 iii  i +* Re: Another security vulnerability6Stephen Fuld
11 Jun 24 iii  i i`* Re: Another security vulnerability5MitchAlsup1
11 Jun 24 iii  i i `* Re: Another security vulnerability4Stephen Fuld
11 Jun 24 iii  i i  `* Re: Another security vulnerability3Terje Mathisen
11 Jun 24 iii  i i   `* SSDs (was: Another security vulnerability)2Stefan Monnier
11 Jun 24 iii  i i    `- Re: SSDs1Chris M. Thomasson
11 Jun 24 iii  i `- Re: Another security vulnerability1MitchAlsup1
11 Jun 24 iii  `- Re: Another security vulnerability1MitchAlsup1
26 Mar 24 ii`* Re: Another security vulnerability2Anton Ertl
26 Mar 24 ii `- Re: Another security vulnerability1Anton Ertl
25 Mar 24 i`- Re: Another security vulnerability1Michael S
25 Mar 24 +* Re: Another security vulnerability22Anton Ertl
26 Mar 24 i`* Re: Another security vulnerability21Michael S
27 Mar 24 i `* Re: Another security vulnerability20Thomas Koenig
27 Mar 24 i  +* Re: Another security vulnerability2Thomas Koenig
27 Mar 24 i  i`- Re: Another security vulnerability1Thomas Koenig
27 Mar 24 i  +- Re: Another security vulnerability1Anton Ertl
27 Mar 24 i  `* Re: Another security vulnerability16Anton Ertl
27 Mar 24 i   `* Re: Another security vulnerability15MitchAlsup1
28 Mar 24 i    +* Re: Another security vulnerability4MitchAlsup1
29 Mar 24 i    i`* Re: Another security vulnerability3Paul A. Clayton
29 Mar 24 i    i `* Re: Another security vulnerability2Paul A. Clayton
30 Mar 24 i    i  `- Re: Another security vulnerability1MitchAlsup1
3 Apr 24 i    `* Re: Another security vulnerability10Stefan Monnier
3 Apr 24 i     `* Re: Another security vulnerability9Thomas Koenig
3 Apr 24 i      +* Re: Another security vulnerability6MitchAlsup1
4 Apr 24 i      i`* Re: Another security vulnerability5Thomas Koenig
4 Apr 24 i      i `* Re: Another security vulnerability4MitchAlsup1
4 Apr 24 i      i  +- Re: Another security vulnerability1MitchAlsup1
7 Apr 24 i      i  `* Re: Another security vulnerability2Paul A. Clayton
8 Apr 24 i      i   `- Re: Another security vulnerability1MitchAlsup1
5 Apr 24 i      `* Re: Another security vulnerability2Stefan Monnier
5 Apr 24 i       `- Re: Another security vulnerability1MitchAlsup1
25 Mar 24 `* Re: Another security vulnerability3John Savard
25 Mar 24  `* Re: Another security vulnerability2Michael S
26 Mar 24   `- Re: Another security vulnerability1Lawrence D'Oliveiro

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal