Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753090AbbGBDHw (ORCPT ); Wed, 1 Jul 2015 23:07:52 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:34360 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753059AbbGBDHb (ORCPT ); Wed, 1 Jul 2015 23:07:31 -0400 MIME-Version: 1.0 In-Reply-To: <1435753306.1134542.312471953.3DCB0D87@webmail.messagingengine.com> References: <4290667.ZqInAykFGS@vostro.rjw.lan> <20150509202518.GB20282@khazad-dum.debian.net> <20150625171158.GB27230@khazad-dum.debian.net> <1435753306.1134542.312471953.3DCB0D87@webmail.messagingengine.com> Date: Wed, 1 Jul 2015 23:07:29 -0400 X-Google-Sender-Auth: L0yAw2Z0JYs2Os8q8lHX3bJpIwM Message-ID: Subject: Re: [PATCH 1/1] suspend: delete sys_sync() From: Len Brown To: Henrique de Moraes Holschuh Cc: Alan Stern , "Rafael J. Wysocki" , One Thousand Gnomes , Linux PM list , "linux-kernel@vger.kernel.org" , Len Brown Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1877 Lines: 41 >> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/