On 01/14/2016 04:47 PM, Paul E. McKenney wrote:> On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote: >> Don't be fooled here by words "ordered" and "completed" - it is HW >> design items and actually written poorly. >> Just assume that SYNC_MB is absolutely the same as SYNC for any CPU >> and coherent device (besides performance). The difference can be in >> non-coherent devices because SYNC actually tries to make a barrier >> for them too. In some SoCs it is just the same because there is no >> need to barrier a non-coherent device (device register access >> usually strictly ordered... if there is no bridge in between). > So smp_mb() can be SYNC_MB. However, mb() needs to be SYNC for MMIO > purposes, correct?Absolutely. For MIPS R2 which is not Octeon.>> Note: I am not sure about ANY past MIPS R2 CPU because that stuff is >> implemented some time but nobody made it in Linux kernel (it was >> used by some vendor for non-Linux system). For that reason my patch >> for lightweight SYNCs has an option - implement it or implement a >> generic SYNC. It is possible that some vendor did it in different >> way but nobody knows or test it. But as a minimum - SYNC must be >> implemented in spinlocks/atomics/bitops, in recent P5600 it is >> proven that read can pass write in atomics. >> >> MIPS R6 is a different story, I verified lightweight SYNCs from the >> beginning and it also should use SYNCs. > So you need to build a different kernel for some types of MIPS systems? > Or do you do boot-time rewriting, like a number of other arches do?I don't know. I would like to have responses. Ralf asked Maciej about old systems and that came nowhere. Even rewrite - don't know what to do with that: no lightweight SYNC or no SYNC at all - yes, it is still possible that SYNC on some systems can be too heavy or even harmful, nobody tested that. - Leonid.
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:> > So you need to build a different kernel for some types of MIPS systems? > > Or do you do boot-time rewriting, like a number of other arches do? > > I don't know. I would like to have responses. Ralf asked Maciej about old > systems and that came nowhere. Even rewrite - don't know what to do with that: > no lightweight SYNC or no SYNC at all - yes, it is still possible that SYNC on > some systems can be too heavy or even harmful, nobody tested that.I don't recall being asked; mind that I might not get to messages I have not been cc-ed in a timely manner and I may miss some altogether. With the amount of mailing list traffic that passes by me my scanner may fail to trigger. Sorry if this causes anybody trouble, but such is life. Coincidentally, I have just posted some notes on SYNC in a different thread, see <http://lkml.iu.edu/hypermail/linux/kernel/1601.3/03080.html>. There's a reference to an older message of mine there too. I hope this answers your questions. Maciej
On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:> On Fri, 15 Jan 2016, Leonid Yegoshin wrote: > >>> So you need to build a different kernel for some types of MIPS systems? >>> Or do you do boot-time rewriting, like a number of other arches do? >> I don't know. I would like to have responses. Ralf asked Maciej about old >> systems and that came nowhere. Even rewrite - don't know what to do with that: >> no lightweight SYNC or no SYNC at all - yes, it is still possible that SYNC on >> some systems can be too heavy or even harmful, nobody tested that. > I don't recall being asked;In http://patchwork.linux-mips.org/patch/10505/ the very last mesg exchange is: Maciej, do you have an R4000 / R4600 / R5000 / R7000 / SiByte system at hand to test this? ... Ralf Maciej W. Rozycki <http://patchwork.linux-mips.org/project/linux-mips/list/?submitter=79> - June 5, 2015, 9:18 p.m. On Fri, 5 Jun 2015, Ralf Baechle wrote:> do you have an R4000 / R4600 / R5000 / R7000 / SiByte system at hand to > test this?I should be able to check R4400 (that is virtually the same as R4000) next week or so. As to SiByte -- not before next month I'm afraid. I don't have access to any of the other processors you named. You may want to find a better person if you want to accept this change soon. Maciej ... and that stops forever... - Leonid. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20160127/265c0eca/attachment.html>
On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:> On Fri, 15 Jan 2016, Leonid Yegoshin wrote: > >>> So you need to build a different kernel for some types of MIPS systems? >>> Or do you do boot-time rewriting, like a number of other arches do? >> I don't know. I would like to have responses. Ralf asked Maciej about old >> systems and that came nowhere. Even rewrite - don't know what to do with that: >> no lightweight SYNC or no SYNC at all - yes, it is still possible that SYNC on >> some systems can be too heavy or even harmful, nobody tested that. > I don't recall being asked; mind that I might not get to messages I have > not been cc-ed in a timely manner and I may miss some altogether. With > the amount of mailing list traffic that passes by me my scanner may fail > to trigger. Sorry if this causes anybody trouble, but such is life. > > Coincidentally, I have just posted some notes on SYNC in a different > thread, see <http://lkml.iu.edu/hypermail/linux/kernel/1601.3/03080.html>. > There's a reference to an older message of mine there too. I hope this > answers your questions. > > MaciejIn http://patchwork.linux-mips.org/patch/10505/the very last mesg exchange is: Maciej, do you have an R4000 / R4600 / R5000 / R7000 / SiByte system at hand to test this? ... Ralf Maciej W. Rozycki- June 5, 2015, 9:18 p.m. On Fri, 5 Jun 2015, Ralf Baechle wrote:> do you have an R4000 / R4600 / R5000 / R7000 / SiByte system at hand to > test this?I should be able to check R4400 (that is virtually the same as R4000) next week or so. As to SiByte -- not before next month I'm afraid. I don't have access to any of the other processors you named. You may want to find a better person if you want to accept this change soon. Maciej ... and that stops forever... - Leonid.