On Thu, Sep 13, 2012 at 10:20:30AM +0800, Raul Xiong wrote: > I have several questions: > 1. Even we call flush_calche_all in __cpu_suspend_save, since later we > will outer_clean_range which may cause cache operations so we still > need to flush again in finisher, right?
Why would it? Any data which would be pulled back into the L1 cache from that point is either going to be clean (in other words, a copy of it exists elsewhere in the system) or it is going to be dirty (in which case, it's been explicitly written to - and that's the stuff the finisher needs to take care of. We do not care abou the dirty data created by calling subsequent functions as this is not used for resuming. > 2. Not every platform the L1 will be lost, we have the option to keep > L1 retentive, right? Just consider single core CA9. So we may not need > to flush all every time. That's where you start paying the price for having such a complex architecture, and the need to have generic code to keep things simple. Rather than thinking "we need to eliminate that flush and move it into the finisher" start thinking "we need to communicate what parts of the system are lost over suspend and get the suspend code to use that to determine what it needs to do". > 3. Why it's difficult to call cache maintenance in assembly? Moreover, > not every finisher is assembly, right? Have you tried to see whether a function called 'flush_cache_all' actually exists in your System.map file? It doesn't. What you have is a bunch of cache specific functions, one of which either gets aliased to that name at build time, or that name gets aliased to a function pointer (in a structure) to point at the relevant cache specific function. And there are platforms where hard-coding just one is not correct. What we have today is a massive improvement over what we had earlier on where every platform was implementing all the suspend/resume stuff themselves. I'm not going back to the situation where we have that again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/