>> The _vast_ majority of systems using Linux suspend today are under >> an Android user-space. Android has no assumption that that suspend to >> mem will necessarily stay suspended for a long time. > > Indeed, however your change was not android-specific, and it is not > "comfortable" on x86-style hardware and usage patterns.
"comfortable on x86-style and usage patterns"? If you mean "traditional" instead of "comfortable", where "tradition" is based on 10-year old systems, then sure. But today, my x86 Android tablet is quite "comfortable" without a sys_sync() in the kernel suspend path. No, this isn't Android specific, Android is just the highest-volume demand, making it an obvious example. Chrome is the #1 selling "x86-style" clamshell laptop. Chrome is not only "comfortable" with fast suspend/resume, the Chrome developers demand it. > That said, as long as x86 will still try to safeguard my data during mem > sleep/resume as it does today, I have no strong feelings about > light/heavy-weight "mem" sleep being strictly a compile-time selectable > thing, or a more flexible runtime-selectable behavior. The observation here is that the kernel should not force every system to sys_sync() on every suspend. The only question is how to best implement that. The obvious solution was to delete this forced policy from the kernel, and let user-space handle it. Rafael has not agreed to push that obvious, though less-than-gentle solution upstream, and so I'll re-send the historic patch that allows distros to still sync like it is 1999, if they want to:-) thanks, Len Brown, Intel Open Source Technology Center -- 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/
