Hi Huacai, On Thu, Sep 06, 2018 at 09:33:15AM +0800, Huacai Chen wrote: > On Thu, Sep 6, 2018 at 12:54 AM, Paul Burton <paul.burton@xxxxxxxx> wrote: > > On Wed, Sep 05, 2018 at 05:33:01PM +0800, Huacai Chen wrote: > >> New Loongson-3 (Loongson-3A R2, Loongson-3A R3, and newer) has SFB > >> (Store Fill Buffer) which can improve the performance of memory access. > >> Now, SFB enablement is controlled by CONFIG_LOONGSON3_ENHANCEMENT, and > >> the generic kernel has no benefit from SFB (even it is running on a new > >> Loongson-3 machine). With this patch, we can enable SFB at runtime by > >> detecting the CPU type (the expense is war_io_reorder_wmb() will always > >> be a 'sync', which will hurt the performance of old Loongson-3). > > > > This looks unchanged since v3, and I didn't see a response to my email > > here: > > > > https://marc.info/?l=linux-mips&m=153248530725061&w=2 > > > > I still haven't seen any explanation for why you can't just do this as a > > one-liner in C, the same way we enable tons of other CPU features during > > cpu_probe(). > > > > I'm not saying I'll never accept the assembly version, but I want an > > explanation for why it's necessary first. If that's not something you > > can give, at least describe in the commit message what goes wrong when > > you try to do it in C as justification for not doing it that way. > > In practise, I found that sometimes there are boot failures if I > enable SFB/LPA in cpu_probe(). I don't know why because processorr > designers also haven't give me an explaination, but I think this may > have some relationships to speculative execution. OK, applied to mips-next for 4.20 with that noted in the commit message. Thanks, Paul
