[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100513211006.GG3428@atomide.com>
Date: Thu, 13 May 2010 14:10:06 -0700
From: Tony Lindgren <tony@...mide.com>
To: Matthew Garrett <mjg@...hat.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
Paul Walmsley <paul@...an.com>,
Arve Hjønnevåg <arve@...roid.com>,
Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
Kevin Hilman <khilman@...prootsystems.com>,
magnus.damm@...il.com, Theodore Ts'o <tytso@....edu>,
mark gross <mgross@...ux.intel.com>,
Arjan van de Ven <arjan@...radead.org>,
Geoff Smith <geoffx.smith@...el.com>,
Brian Swetland <swetland@...gle.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Benoît Cousson <b-cousson@...com>,
linux-omap@...r.kernel.org, Vitaly Wool <vitalywool@...il.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett <mjg@...hat.com> [100513 13:29]:
> On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg@...hat.com> [100513 13:03]:
> > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
> > >
> > > > The system stays running because there's something to do. The system
> > > > won't suspend until all the processors hit the kernel idle loop and
> > > > the next_timer_interrupt_critical() returns nothing.
> > >
> > > At which point an application in a busy loop cripples you.
> >
> > Maybe you could deal with the misbehaving untrusted apps in the userspace
> > by sending kill -STOP to them when the screen blanks? Then continue
> > when some event wakes up the system again.
>
> And if that's the application that's listening to the network socket
> that you want to get a wakeup event from? This problem is hard. I'd love
> there to be an elegant solution based on using the scheduler, but I
> really don't know what it is.
Your system should wake up to an interrupt in that case. Then you have
the trusted apps running that can decide if the untrusted apps should
be continued or not.
The key would be to have the basic apps behave and use the critical
timers as needed. The advantage is that then you can do all the
policy in the userspace and in a custom pm_idle function.
Regards,
Tony
--
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