From: Pavel Machek <pavel@suse.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: stern@rowland.harvard.edu, rjw@sisk.pl,
linux-kernel@vger.kernel.org, ncunningham@crca.org.au,
linux-pm@lists.linux-foundation.org
Subject: Re: [linux-pm] Freezer: Don't count threads waiting for frozen filesystems.
Date: Sat, 15 Nov 2008 17:58:51 +0100 [thread overview]
Message-ID: <20081115165851.GA1523@ucw.cz> (raw)
In-Reply-To: <E1KvYgR-0002Cx-AZ@pomaz-ex.szeredi.hu>
Hi!
> > > > I don't know. There are other interfaces too, like sysfs attributes,
> > > > that would have to be handled specially. On the whole, the freezer
> > > > seems much, much simpler.
> > >
> > > OK, then non-device files on "regular" filesystems.
> >
> > Would you like to write a first-pass patch? I don't think it will
> > work.
>
> If somebody doesn't beat me to it, I'll do that (first implemented
> with a global rw-sem).
Cool!
l
> > Doing that seems like a lot of work, just as modifying every driver
> > does. Changing a few kernel entry points is simpler, but I'm pretty
> > sure it won't work. For instance, tasks can block arbitrarily long on
> > read calls (waiting for data to arrive); you can't allow such things to
> > prevent the system from suspending.
>
> But we already do: either
>
> a) it's in interruptible sleep (I/O on sockets, pipes, etc), and
> freezing simply interrupts it, or
>
> b) it's in uninterruptible sleep and suspend will wait it out (or
> time out).
>
> In the new scheme we could retain that part of the freezer: interrupt
> all tasks which are inside the critical region and wait for them to
> exit the critical region.
>
> To put it in another way: it's still the freezer, it does all the same
> things as the old freezer, except that the condition for freezing is
> not that the task is out of the kernel, rather that it's out of the
> disable_supend - enable_suspend region. As such it's not a big change
> to the whole suspend system, and so there shouldn't be anything big
> going wrong there.
Disadvantage is it will add overhead to regular syscalls, at least
initialy. That's why I implemented freezer initialy...
Of course, suspend is more important than it was back then, and
disadvantages of freezer are now well known, so maybe a little
overhead in exchange of cleaner design is worth it...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2008-11-15 16:59 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1224886068.6478.21.camel@nigel-laptop>
2008-10-26 20:01 ` Rafael J. Wysocki
2008-10-27 11:12 ` Miklos Szeredi
2008-10-27 11:20 ` Nigel Cunningham
2008-10-27 11:37 ` Rafael J. Wysocki
2008-10-27 11:40 ` Nigel Cunningham
2008-10-27 12:38 ` Miklos Szeredi
2008-10-27 20:59 ` Nigel Cunningham
2008-10-27 21:09 ` Miklos Szeredi
2008-10-27 22:13 ` Nigel Cunningham
2008-10-28 20:25 ` Miklos Szeredi
2008-10-28 21:29 ` Nigel Cunningham
2008-10-28 21:51 ` Miklos Szeredi
2008-10-28 22:00 ` Rafael J. Wysocki
2008-10-28 22:02 ` Miklos Szeredi
2008-10-28 22:21 ` Rafael J. Wysocki
2008-10-28 23:21 ` Miklos Szeredi
2008-10-28 23:59 ` Rafael J. Wysocki
2008-10-29 8:10 ` Miklos Szeredi
2008-10-29 13:51 ` Alan Stern
2008-10-29 14:50 ` Miklos Szeredi
2008-10-29 15:28 ` Alan Stern
2008-10-29 15:50 ` Miklos Szeredi
2008-10-29 16:17 ` Alan Stern
2008-10-29 16:10 ` Miklos Szeredi
2008-10-29 20:37 ` Alan Stern
2008-10-29 21:11 ` Rafael J. Wysocki
2008-10-29 21:45 ` Nigel Cunningham
2008-10-29 22:07 ` Rafael J. Wysocki
2008-10-29 23:53 ` Miklos Szeredi
2008-11-09 13:44 ` Pavel Machek
2008-10-29 23:48 ` Miklos Szeredi
2008-10-30 13:04 ` Nigel Cunningham
2008-10-30 13:56 ` Alan Stern
2008-10-30 21:44 ` Nigel Cunningham
2008-10-31 8:49 ` Miklos Szeredi
2008-10-31 9:10 ` Nigel Cunningham
2008-10-31 9:16 ` Miklos Szeredi
2008-10-31 11:28 ` Nigel Cunningham
2008-10-31 12:44 ` Miklos Szeredi
2008-10-31 21:11 ` Nigel Cunningham
2008-10-29 23:43 ` Miklos Szeredi
2008-10-30 13:54 ` Alan Stern
2008-10-30 14:39 ` Miklos Szeredi
2008-10-30 17:07 ` Alan Stern
2008-10-30 17:43 ` Miklos Szeredi
2008-10-30 20:17 ` Rafael J. Wysocki
2008-11-15 16:58 ` Pavel Machek [this message]
2008-10-29 23:56 ` Matthew Garrett
2008-10-28 22:03 ` Nigel Cunningham
2008-10-28 23:04 ` Nigel Cunningham
2008-10-28 23:12 ` Miklos Szeredi
2008-10-28 23:17 ` Nigel Cunningham
2008-10-28 23:24 ` Miklos Szeredi
2008-10-28 23:41 ` Nigel Cunningham
2008-10-28 23:45 ` Miklos Szeredi
2008-10-28 23:50 ` Miklos Szeredi
2008-10-28 23:58 ` Nigel Cunningham
2008-10-28 23:54 ` Nigel Cunningham
2008-10-27 11:37 ` Miklos Szeredi
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=20081115165851.GA1523@ucw.cz \
--to=pavel@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=miklos@szeredi.hu \
--cc=ncunningham@crca.org.au \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
/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
all inboxes | Powered by JetHome®