From: Jonas Meurer <jonas@freesources.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-pm@vger.kernel.org, Len Brown <len.brown@intel.com>,
Tim Dittler <tim.dittler@systemli.org>
Subject: Re: [RFC PATCH] PM: Add a switch for disabling/enabling sync() before suspend
Date: Thu, 31 Oct 2019 16:56:04 +0100 [thread overview]
Message-ID: <1a180a7e-265d-f4c8-1cdd-ecafe72cf0a0@freesources.org> (raw)
In-Reply-To: <20191022103909.GA10573@amd>
Hi Pavel,
thanks for your comment.
Pavel Machek:
>> sorry for the noise, but again: is there a chance to get a brief review
>> of my patchset?
>>
>> Probably it was a bad idea to rename the build-time flag, right? Should
>> I revert that part of the patch?
>
> I don't like adding more and more knobs.
>
> We should not have added that compile-time option, either.
>
> Perhaps it is time to declare that if the user wants the data to be
> synced, he just does sys_sync() himself?
Mh, I don't see why you would want to do that? In most standard cases, I
think it's perfectly reasonable that the kernel takes care of a final
sync() before doing suspend to RAM in order to prevent potential data
loss when the system looses power during suspend mode.
> (Yes, that will mean tiny ammount of dirty data created between
> sys_sync() and suspend to be unwritten, but...)
>
> (Besides, if you add a runtime option to avoid deadlocks, you still
> have not fixed the deadlocks...)
The deadlock only happens if something outside the kernel suspends the
block devices *before* doing suspend to RAM. In this edge case, the
runtime option would help a lot.
Besides, what you suggest probably requires a lot more discussion than
adding a runtime option, no? Would you be ok with adding the runtime
switch now and discuss the removal of sync() from suspend function
altogether later?
Cheers
jonas
prev parent reply other threads:[~2019-10-31 15:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 10:50 [RFC PATCH] PM: Add a switch for disabling/enabling sync() before suspend Jonas Meurer
2019-10-10 15:00 ` Jonas Meurer
2019-10-11 10:22 ` Rafael J. Wysocki
2019-10-14 17:46 ` Jonas Meurer
2019-10-14 17:48 ` [PATCH v2 1/2] " Jonas Meurer
2019-10-14 17:49 ` [PATCH v2 2/2] PM: Change CONFIG_SUSPEND_SKIP_SYNC to CONFIG_SKIP_SYNC_ON_SUSPEND Jonas Meurer
2019-11-04 10:51 ` [PATCH v3 2/2] PM: CONFIG_SUSPEND_SKIP_SYNC sets default for '/sys/power/sync_on_suspend' Jonas Meurer
2019-10-21 10:47 ` [RFC PATCH] PM: Add a switch for disabling/enabling sync() before suspend Jonas Meurer
2019-10-21 21:47 ` Rafael J. Wysocki
2019-10-22 8:54 ` Jonas Meurer
2019-11-04 10:57 ` Jonas Meurer
2019-11-12 11:00 ` Jonas Meurer
2019-12-02 14:12 ` Yannik Sembritzki
2019-12-02 17:05 ` Jonas Meurer
2019-10-22 10:39 ` Pavel Machek
2019-10-31 15:56 ` Jonas Meurer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1a180a7e-265d-f4c8-1cdd-ecafe72cf0a0@freesources.org \
--to=jonas@freesources.org \
--cc=len.brown@intel.com \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=tim.dittler@systemli.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).