Hi Shreyas, On 04/14/2015 07:26 AM, Shreyas B. Prabhu wrote: > Fastsleep is one of the idle state which cpuidle subsystem currently > uses on power8 machines. In this state L2 cache is brought down to a > threshold voltage. Therefore when the core is in fastsleep, the > communication between L2 and L3 needs to be fenced. But there is a bug > in the current power8 chips surrounding this fencing. > > OPAL provides a workaround which precludes the possibility of hitting > this bug. But running with this workaround applied causes checkstop > if any correctable error in L2 cache directory is detected. Hence OPAL > also provides a way to undo the workaround. > > In the existing implementation, workaround is applied by the last thread > of the core entering fastsleep and undone by the first thread waking up. > But this has a performance cost. These OPAL calls account for roughly > 4000 cycles everytime the core has to enter or wakeup from fastsleep. > > This patch introduces a sysfs attribute (fastsleep_workaround_state) > to choose the behavior of this workaround. > > By default, fastsleep_workaround_state = dynamic. In this case, workaround > is applied/undone everytime the core enters/exits fastsleep. > > fastsleep_workaround_state = applyonce. In this case the workaround is > applied once on all the cores and never undone. This can be triggered by > echo applyonce > /sys/devices/system/cpu/fastsleep_workaround_state
I was wondering if we really need such an elaborate design for this sysfs file. Why not a sysfs file called fastsleep_workaround_apply_once, which is set to '0' by default and the only value that it can take is '1' ? The name easily implies that the workaround is applied only once if it is set. I can see that this can cut down a good chunk of code from this patch. I just didn't find too much value in having so much code for a simple 'on' knob. Regards Preeti U Murthy -- 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/
