- 2012-07-16 16:22:48
OS保证cache一致性所拥有的武器validating main memory把cache line同步到memory，cache line的修改位被清空invalidating cache把cache line删除掉。一般针对过时数据。两种方法可以组合起来使用，现使用validating main memory把需要同步的数据同步到memory中，然后flush掉cachevirtual cachewrite through写命中，MMU检查权限是否可写，可写的话，就从把数据替换进cache line,同时写入memory。不可写的话，cache没有任何变化。写缺失，如果支持写分配，MMU检查权限，如果可写，从memory中把数据读入cache line，然后把写入的数据填入cahce line,同时写入memory，否则cache没有任何变化。如果不支持写分配，MMU检查权限，如果可写，只把数据写入memory，cache没有任何变化。write back写命中，如果cache line是被修改位有标记，说明cache line对应的memory是有可写权限的。不需要再使用MMU检查，直接把数据写入cache line。（注：如果权限发生了变化，OS会flush cache),如果cache line的修改位没有标记，就不清楚写权限了。这个时候又需要MMU来检查权限了。如果可写，数据写入cache line,标记修改位写缺失，如果支持写分配，MMU检查权限，如果可写，从memory中读取cache line,数据写入cache line，标记修改位。如果不可写，cache不变。如果不支持写分配，检查MMU，如果可写，把数据写入memory,不可些的话,cache没有任何变化。（注：有些CPU为了减少MMU对权限的检查，加入了可写位） 歧义：同样的虚拟地址先后指向不一样的物理地址。 会从cache中读取到错误的数据。OS确保在虚拟空间发生任何变化前，把数据写回到memory中。别名:不同的虚拟地址指向了同样的物理地址。会造成数据的不一致。不同的虚拟地址不只指单进程内，多进程之间也可能发生别名。OS来解决。。不过没有写怎么解决。。注：书中描述的cache是VIVT的。对于别名，即cache alias以及解决方案。转载了一下内容（VIPT的）转自：http://blog.sina.com.cn/s/blog_620086950100u80z.htmlWe have to consider how virtually-indexed-physically-tagged (VIPT) cacheshould be handled in both MI and MD layer.As mentioned in the Curt Schimmel's book (ISBN 0-201-63338-8),pure virtually-indexed cache system has two problem,that are ambiguity and alias.Ambiguity means "different PAs are mapped into the same VA,"and alias means "the same PA is mapped into different VAs."The operating system has to handle these problems by cache flushor disabling cache against such addresses.On the other hand, VIPT cache system uses physical address tagto see if the cacheline is hit, so the ambiguity problem won'thappen, because cache tags never match against different PAs.But alias still could happen on VIPT cache systems becauseif the same PA is mapped into the different VAs, they could havedifferent virtual indexes and certainly has the same physical tags,so multiple cacheline might have data for the single PA.On usual VM system, virtual address space is managed per page,so PGOFSET bits are always same between VA and PA. ThenPGOFSET bits of virtual address cache indexes are always sameif mapped VAs shares the same physicall address page.If the number of "cachelinesize * number-of-indexes"(or "cachesize / number-of-ways") is same with or smaller thanpagesize, virtual indexes against the same PA are always sameso alias won't happen.The alias could happen only if the number is larger than pagesize.On 4KB/page system, if CPU has 8KB direct mapped (== 1 way) cache,data in single physical address could have two possible virtual indexes.If CPU has 32KB two-way set associative cache, one PA could havefour possible virtual indexes. I don't know what this "how manypossible virtual indexes against the same PA" should be called,but I'd call it "number of virtual cache page index" here.On 4KB/page and 16KB direct mapped cache system (i.e. SH7750),bit [13:12] in VA indicates the "virtual cache page index" of the VA.The problem mentioned in this PR is caused by the method"how we should avoid the alias problem when the same PA mapped intothe different VAs which have different virtual cache page indexes"on current sh3 pmap. Currently it just only allows one mappingfor each physicall address at a time regardless of its virtual cachepage indexes.The problem happens if a page where the program running is alsomapped into different VA, and the current instruction tries to accesssuch VA (which has the same PA with the VA where the program running).The access to the VA causes a fault, pmap_enter(9) is called,and the VA where the program running will be unmapped by the pmap,another page fault will happen as soon as the first fault isreturned, then stuck on infinite loop.AFAIK, there is only one possible strategy to fix this situationin MD pmap:- allow multiple mappings for single PA if mapped VA have different virtual cache page indexesAND- make VA pages uncached if the requested VAs to be mapped for single PA have different virtual cache page indexesThis is what current mips pmap does for CPUs with R4K style. MMU.My previous patch for current sh3 pmap only does the former.Of cource, making pages uncached may cause serious performance hits,so the MI VM system and the dynamic linker should also considerabout this alias problem on VIPT cache system.Unfortunately there is almost nothing in them, so current mips(and sh4) pmap has a bunch of (possibly avoidable) cache flush ops.See pmap_copy(9) or pmap_zero(9) functions etc. in mips and sh3 pmaps.Note this alias problem could happen even if new VA is mappedeven after the previously mapped VA is unmapped unlesscache data against the previously mapped VA is explicitly flushed.On pure virtual cache systems, we can't avoid sucha bunch of cache flush ops, so that is weak point of it.But on VIPT cache system, maybe we could most of(or only a certain number of?) flush ops becausethe possible virtual cache page indexes are not so large(usually 2~4, or possibly 8).If the MI VM (and the dynamic linker) could keep a restriction that"single PA can be mapped into only VAs which have the samevirtual cache page index," no cache flush ops are needed.But maybe such restriction is not likely, so only thingwe can do is to avoid PA mappings into VAs which havedifferent virtual cache page indexes "as much as possible."On the MI VM system, we could add some hint value in struct vmpagewhich indicates virtual cache page index where the page waspreviously mapped. If all cache data for the page is flushedexplicitly, the hint value could be "wildcard".If we can know VA before actual mappings, we could usethis hint value to select which free vmpage should be used, andpmap_copy(9) and pmap_zero(9) to select reserved VAs for their ops.Chuck Silvers has some idea about this. We already have multiplefreelists (for physical cache coloring) in uvm_pagelist.c, soit might be trivial to prepare extra buckets for each virtual pageindex (and wildcard).If we can use any VA to create shared mapping, we can just chooseappropriate VA which has the same virtual cache page indexif uvm_km_alloc(9) family is changed to take such index argument.On the dynamic linker, it can't know the number of virtual cachepage index at runtime, maybe we have to define maximam number of itin ABI of each CPU so that all shared mapping always could havethe same virtual cache page index.(I'm not sure if this is really possible though)Anyway, I'm afraid that the "proper" fixes against MI system andABIs can't happen for some time (or forever?), so just fixing MD pmap(multiple VA mapping handling mentioned above) is the only way to gofor now.
[已注销]对本书的所有笔记 · · · · · ·
顺序存储模型(sequential memory model) CPU按照program oder来执行所有的load store指令 ...
说明 · · · · · ·