IRC logs for #openrisc Sunday, 2017-12-03

--- Log opened Sun Dec 03 00:00:42 2017
bandvigLet me describe background of my question.04:38
bandvigActually, I'm not expert in multi-processor systems. Now I'm reading Culler's book "Parallel Computer Architecture".04:39
bandvigIf I understand correctly, designing a SMP machine we should make decision which kind of memory consistency model the machine will implement.04:39
bandvigThe model could be: (a) one of an academic variant like Sequential Consistency (SC) or Processor Consistency (PC) etc04:39
bandvig(b) one of an industry variant like SPARC's Total Store Order (TSO) or Partial Store Order (PSO)04:39
bandvig(c) something self designed.04:40
bandvigVarious hardware solutions like atomic and memory synch. instructions or04:40
bandvigcaches architecture and cache synch. should be designed in the way to provide SMP machine functioning04:40
bandvigin according with selected memory consistency model.04:41
bandvigWhile internally in hardware we can use various tricks to speed up our SMP system,04:41
bandviga programmer should continue view declared consistency model.04:41
bandvigWe can build simple SMP machine which sequentially consistent using just04:41
bandvigsingle level write-through snoop-invalidation caches (without write buffers !!!) and appropriately integrated l.lwa/l.swa execution.04:42
bandvigNext we can implement various synchronization algorithms with  l.lwa/l.swa in assumption04:42
bandvigthat our SMP machine is sequentially consistent.04:42
bandvigHowever if we add write buffers in our HW design04:42
bandvigthey destroy sequential consistency and our previously designed soft has become malfunctioning.04:43
bandvigWe have either to implement some trick in hardware to keep SC from programmer view (I'm not sure that is possible for the example)04:43
bandvigor declare another  memory consistency model for our (another now !!!) SMP machine (like SPRAC's TSO for example).04:43
bandvig For the second variant we have to redesign our SMP soft libraries.04:43
bandvigOR1K spec is quite unclear regarding multi-processor systems.04:43
bandvig"The OpenRISC 1000 architecture specifies a weakly ordered memory model for uniprocessor and shared memory multiprocessor systems ".04:44
bandvigIf I understand correctly "weak order" or "strong order" are not describe memory consistency model them selfs04:44
bandvigThey are comparative categories. For example, TSO is weakly than SC, but stronger than PSO.04:44
bandvigSo, OR1K spec does not tell anything about how to build multi-core OpenRISC system.04:46
bandvigwallento: If I understand correctly a tile of OpTiMSoC could be an SMP machine.04:46
bandvigwallento: If so, could your describe in several words which consistency model is used inside a tile and how it matches to hardware decisions?04:46
wallentobandvig, I think 1.2 is supposed to help there05:24
wallentobut I agree we should clearer work this out05:25
wallentothe main reason is that there are no high performance cores where it matters05:25
wallentomor1kx is TSO I think with the store buffer05:26
wallentoI propose you start a proper thread on the mailing list for that with the clear goal to make the spec better in this respect05:27
wallentoI think we should keep the consistency model simple and with the common use case of OpenRISC in mind05:36
shornebandvig: right, that much detail is not there, spec verions 1.2 (released a few weeks, months back) tries to explain the options a bit06:01
shornebut does not get into TSO/PSO details, also one thing I see in other architecture is the memory barriers (write barrier, read barrier) which we dont really have06:02
shornewe just depend on the lwa/swa pairs and cache coherency via sync06:03
shorneProbably we can do what we always do any find a architecture or architecutes we like and compare their models and spec and see which fits best.  It would be good to discuss on the list06:05
bandvigshorne: If I understand correctly, TSO machine needn't barriers but for PSO and SPARC's V9 Relaxed Memory Order (RMO) they are mandatory.06:53
bandvigBy the way, here is an interesting article06:53
bandvigthere proven that TSO/PSO could be correctly implemented on machine with write buffers while RMO couldn't.06:54
bandvigI've downloaded 1.2 spec. Today or tomorrow I'll write in mailing list some initial latter regarding multi-core spec.06:56
shornebandvig: thank you, I think we have TSO now, but if there is benefit to relax it to PSO or RMO I have no objection if people really want it, just more bugs to fix in the kernel :)07:06
shorneBUt probably no one sane would would to go with a really relaxed model like alpha had07:07
shornebandvig: if you haven't read, this one is really good too
--- Log closed Mon Dec 04 00:00:43 2017

Generated by 2.15.2 by Marius Gedminas - find it at!