您的位置:首页 > 教育 > 锐评 > 前端网页设计师_保亭整站优化_如何建立企业网站_单页网站

前端网页设计师_保亭整站优化_如何建立企业网站_单页网站

2025/2/23 13:35:22 来源:https://blog.csdn.net/qq_40147893/article/details/145800998  浏览:    关键词:前端网页设计师_保亭整站优化_如何建立企业网站_单页网站
前端网页设计师_保亭整站优化_如何建立企业网站_单页网站

在这里插入图片描述

文章目录

    • 4.6 Silent cache state transitions
    • 4.7 Cache state transitions at a Requester
      • 4.7.1 Read request transactions
      • 4.7.2 Dataless request transactions
      • 4.7.3 Write request transactions
      • 4.7.4 Atomic transactions
      • 4.7.5 Other request transactions


4.6 Silent cache state transitions

  缓存可以由于内部事件而改变状态,而无需通知系统的其余部分。

合法的静默缓存状态转换如下表所示。 在某些情况下,可以但不要求发出事务以指示转换已发生。 如果发出了这样的事务,则缓存状态转换对互连是可见的,并且不被归类为静默转换。

下表中描述的RN-F动作为Local sharing,描述了RN-F将Unique缓存行指定为Shared的情况,有效地忽略了缓存行对RN-F保持Unique的事实。例如,当RN-F包含多个内部代理并且缓存行在它们之间共享时,就会发生这种情况。

对于静默缓存状态转换:

  • Cache eviction and Local sharing转换可以在任何时刻发生。
  • Store和Cache Invalidate转换只能作为故意操作的结果发生,在核心的情况下,这是由执行特定程序指令引起的。

下表备注列指示如何使静默缓存转换变为非静默或在接口上可见。

在这里插入图片描述
缓存状态从UC变为UCE是不允许的。

静默转换的序列也可以发生。 任何导致缓存行处于UD、UDP或SC状态的静默转换都可以进行进一步的静默转换。

4.7 Cache state transitions at a Requester

本节指定以下请求事务的缓存状态转换和完成响应:

  • Read request transactions
  • Dataless request transactions
  • Write request transactions
  • Atomic transactions
  • Other request transactions

4.7.1 Read request transactions

  下表显示了请求者的缓存状态转换及读取请求事务的完成响应,除了 MakeReadUnique 事务。

从属节点对请求者的数据响应中的缓存状态为 UC,即 CompData_UC,无论原始请求类型如何。 请求者必须忽略在对 ReadNoSnp、ReadOnce、ReadOnceCleanInvalid 和 ReadOnceMakeInvalid 的 CompData响应中的缓存状态,并隐式假设缓存状态值为 I。

在非 DMT 数据传输中,CompData 响应从从属发送到主节点,响应中的缓存状态可以是 I 或 UC。通常,预计从属的设计可以通过始终使用 UC 来简化。然后,主节点将带有适当缓存状态值的 CompData 发送给请求者。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
a. 对于ReadOnce*, ReadNotSharedDirty and ReadShared事务,请求者在初始状态为 UCE 时,必须在请求未完成时不将缓存行升级为 UDP 或UD。

b. 处于初始状态 SD 的请求者如果接收CompData_SC 或DataSepResp_SC响应,必须保持在 SD 状态。 同样,使用Snoop filter来跟踪请求者的缓存状态的主节点,必须不根据对请求者的响应中的状态来降低Snoop filter中缓存行的状态。

c. 如果缓存状态为 UD 或 SD,则从内存接收到的数据必须被丢弃;如果缓存状态为 UDP,则必须合并从内存接收到的数据。当缓存状态为 SC 或 UC 时,从内存接收到的数据必须与缓存的数据相同。

MakeReadUnique transaction
本节描述了请求者在 MakeReadUnique 和 MakeReadUnique(Excl) 事务中的允许响应和缓存状态转换。

Permitted responses
下表显示了 MakeReadUnique 事务中的允许响应。

允许响应的一些关键特性包括:

  • 没有数据的响应 Comp_UD_PD 表示请求者正在承担Dirty缓存行的责任。
    当请求者持有缓存行的SharedClean副本,而另一个代理持有SharedDirty时,这种情况可能会发生。 主节点使SharedDirty无效,例如使用 SnpMakeInvalid 事务,然后将脏缓存行的责任传递给发出 MakeReadUnique 事务的请求者。

  • 仅在响应Exclusive版本的 MakeReadUnique 时,才允许具有 SC 缓存状态的响应。
    Comp_SC 是具有 SC 缓存状态的响应的一个示例,当主节点确定独占存储失败,但 snoop filter或对请求者的 SnpQuery snoop 的响应表明请求者仍持有缓存行的副本,同时系统中还有另一个共享副本时,会发送该响应。

上述情况可能发生在非全地址 PoC 独占监视器中。 一个LP可以通过另一个LP对不同地址位置执行独占存储来重置监视位。 对不同地址的存储不会使第一个请求者正在进行独占访问的地址位置的缓存副本失效。

下表显示了在非独占和独占MakeReadUnique事务中允许的响应。
在这里插入图片描述
在这里插入图片描述
下表显示了在独占MakeReadUnique事务中额外允许的响应。
在这里插入图片描述
预期的Snoop
主节点使用Snoop来使Snoopee的缓存行失效,以响应非独占的 MakeReadUnique 或通过独占检查的独占 MakeReadUnique,具体如下:

  • 主节点预计使用 SnpCleanInvalid 窥探:
    — 主节点可以使用 SnpUnique 代替 SnpCleanInvalid。
    — 如果主节点确定请求者丢失了缓存行的缓存副本,则可以使用 SnpUniqueFwd。
    — 如果主节点确定Snoopee没有缓存行的脏副本,则也可以使用 SnpMakeInvalid 代替 SnpCleanInvalid。

Cache line state transitions
  MakeReadUnique 事务后缓存行的最终状态取决于事务响应收到之前缓存行的状态。 这可能与事务发出时缓存行的状态不同。

对于 MakeReadUnique,请求者必须保留缓存行的副本,除非它收到invalidating snoop。

  • Invalidating snoops包括 SnpUnique、SnpUniqueFwd、SnpCleanInvalid、SnpMakeInvalid、SnpUniqueStash 和 SnpMakeInvalidStash。
  • 请求者可以将 SnpPreferUnique 和 SnpPreferUniqueFwd 视为invalidating或non-invalidating。 主节点可以通过检查snoop响应来确定这些snoop如何被Snoopee处理。
  • 所有其他snoop都是non-invalidating的,请求者必须保留缓存行的副本。

如果主节点没有 SF,或者 SF 不精确,并且主节点无法确定请求者在事务完成时是否仍然拥有缓存行的副本,则主节点必须假设缓存行在请求者处丢失,并在响应中提供数据。

在持有 SD 状态的行时,接收到带有数据的响应的请求者必须使用其自己的缓存行副本,而不是响应中返回的副本。

一个请求者在持有SD状态的缓存行时接收到带有数据的响应,这意味着系统中没有snoop filter或snoop filter不精确。 在这种情况下,返回的响应数据可能是过时的。

如果请求者知道没有snoop filter,那么它可以使用CleanUnique事务,而不是MakeReadUnique,以避免在缓存行未被其他代理缓存时进行不必要的内存读取。

在没有snoop filter的情况下,使用CleanUnique事务可以避免不必要的内存读取。 不必要的内存读取发生在缓存行仍然在请求者处缓存,但系统中没有snoop filter,或者没有使用SnpQuery snoop ,并且系统中没有来自其他代理的缓存副本。 然而,在事务进行中,如果缓存行因snoop 而丢失,使用CleanUnique事务将导致请求者需要发出另一个事务。

响应规则为:

  • 对非独占MakeReadUnique的响应中的缓存状态必须是Unique的。
  • 对独占MakeReadUnique的响应中的缓存状态可以是Unique的或Shared的。
  • 对独占和非独占MakeReadUnique的响应中的缓存状态不得包含Shared Dirty。
  • 对于每个允许的组合完成和数据响应,允许对应的单独完成和数据响应。

下表展示了
• 初始缓存状态。
• 在接收到事务响应之前的缓存状态。
• 每个可能响应组合的最终状态。

在这里插入图片描述

在这里插入图片描述

4.7.2 Dataless request transactions

下表显示了请求者的缓存状态转换及Dataless请求事务的完成响应。
在这里插入图片描述
在执行CleanInvalid、CleanInvalidPoPA、MakeInvalid或Evict事务之前,缓存状态可以是UC、UCE或SC。然而,要求在发出事务之前,缓存状态必须转换为I状态。

4.7.3 Write request transactions

下表显示了请求者的缓存状态转换、写数据响应,以及写入和相应的组合写请求事务的完成或单独完成和 DBIDResp 响应。
在这里插入图片描述
在这里插入图片描述
a. 在写入待处理时,可能会收到一个snoop,这会导致缓存行状态在 WriteData 或 CompAck 响应之前发生变化。
b. 如果主节点决定不请求数据,则发送 Comp。
c. 一旦请求发送,请求者被允许将缓存状态保持为 UC,但不得修改缓存行。

在 WriteClean 事务完成后,处于Unique状态的缓存行可以立即转换为Dirty状态。

4.7.4 Atomic transactions

下表显示了请求者的缓存状态转换,以及原子事务的完成和响应。
在这里插入图片描述

4.7.5 Other request transactions

DVMOp 和 PrefetchTgt 请求没有与之相关的缓存状态转换。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com