[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4717747.DX2SLP8TIR@linux-5eaq.site>
Date: Thu, 02 May 2013 15:05:13 +0200
From: Oliver Neukum <oneukum@...e.de>
To: Pavel Machek <pavel@....cz>
Cc: Colin Cross <ccross@...roid.com>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
arve@...roid.com, Len Brown <len.brown@...el.com>
Subject: Re: [PATCH 03/10] freezer: add new freezable helpers using freezer_do_not_count()
On Thursday 02 May 2013 14:48:26 Pavel Machek wrote:
> On Mon 2013-04-29 14:45:39, Colin Cross wrote:
> > Freezing tasks will wake up almost every userspace task from
> > where it is blocking and force it to run until it hits a
> > call to try_to_sleep(), generally on the exit path from the syscall
> > it is blocking in. On resume each task will run again, usually
> > restarting the syscall and running until it hits the same
> > blocking call as it was originally blocked in.
>
> Ok, so you are optimizing suspend at the cost of runtime operations,
> right?
>
> Would it make sense to do suspends entirely without freezer in your
> configurations? With the right drivers, it should work ok.
Right now drivers now that they will not be busy when runtime
suspend happens. The freezer has the same effect for system PM.
If you remove that certainty it becomes impossible for simple drivers
to declare their devices busy upon open and do no synchronization
between IO and PM.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists