On Thu, Sep 5, 2013 at 8:04 PM, Evan Dandrea wrote:
> On 5 September 2013 18:35, Steve Langasek wrote:
>>> Is this a proposal for 13.10?
>>
>> I think it's unrealistic to think anything discussed here would land for
>> 13.10. We already have plenty of other things on our plate that are on the
>>
On 09/09/2013 01:09 AM, Alberto Mardegan wrote:
> On 09/05/2013 08:09 PM, Jamie Strandboge wrote:
>> On 09/05/2013 07:01 AM, Alberto Mardegan wrote:
>>> Well, if we don't have a myAppIsRunning() API, apps can simply
>>> busy-loop whenever they want, so I don't see much harm in adding
>>> this API.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/05/2013 08:09 PM, Jamie Strandboge wrote:
> On 09/05/2013 07:01 AM, Alberto Mardegan wrote:
>> Well, if we don't have a myAppIsRunning() API, apps can simply
>> busy-loop whenever they want, so I don't see much harm in adding
>> this API. We coul
On 5 September 2013 18:35, Steve Langasek wrote:
>> Is this a proposal for 13.10?
>
> I think it's unrealistic to think anything discussed here would land for
> 13.10. We already have plenty of other things on our plate that are on the
> critical path for 13.10. :)
Agreed :)
> Anyway, point tak
On 09/05/2013 07:01 AM, Alberto Mardegan wrote:
> On 09/05/2013 12:42 PM, Colin Ian King wrote:
>> On 05/09/13 10:33, Colin Ian King wrote:
>>> On 05/09/13 10:23, Evan Dandrea wrote:
Stuart Langridge brought up an interesting idea for this on IRC, which
I'm copying here rather than having
On Wed, Sep 04, 2013 at 11:52:53AM -0400, Tony Espy wrote:
> On 09/04/2013 05:49 AM, Evan Dandrea wrote:
> > In another discussion, James Hunt raised the possibility of
> > periodically checking for runaway processes on Touch, killing those
> > consuming 100% CPU while creating a report to be sent
On 09/05/2013 04:39 PM, Thomas Voß wrote:
> Hmmm, effectively extending the ANR approach to non-UI bits. That is
> interesting idea. Admittedly, an app could work around that, too, but
> hey :) Further extending on the idea: Whenever we identify a process
> that is using too much CPU over a certain
On Thu, Sep 5, 2013 at 3:49 PM, Colin Ian King wrote:
> On 05/09/13 14:39, Thomas Voß wrote:
>> On Thu, Sep 5, 2013 at 3:25 PM, Joe Talbott
>> wrote:
>>> On Thu, Sep 05, 2013 at 03:01:37PM +0300, Alberto Mardegan wrote:
On 09/05/2013 12:42 PM, Colin Ian King wrote:
> On 05/09/13 10:33,
On 05/09/13 14:39, Thomas Voß wrote:
> On Thu, Sep 5, 2013 at 3:25 PM, Joe Talbott wrote:
>> On Thu, Sep 05, 2013 at 03:01:37PM +0300, Alberto Mardegan wrote:
>>> On 09/05/2013 12:42 PM, Colin Ian King wrote:
On 05/09/13 10:33, Colin Ian King wrote:
> On 05/09/13 10:23, Evan Dandrea wrote
On Thu, Sep 5, 2013 at 3:25 PM, Joe Talbott wrote:
> On Thu, Sep 05, 2013 at 03:01:37PM +0300, Alberto Mardegan wrote:
>> On 09/05/2013 12:42 PM, Colin Ian King wrote:
>> > On 05/09/13 10:33, Colin Ian King wrote:
>> >> On 05/09/13 10:23, Evan Dandrea wrote:
>> >>> Stuart Langridge brought up an i
On Thu, Sep 05, 2013 at 03:01:37PM +0300, Alberto Mardegan wrote:
> On 09/05/2013 12:42 PM, Colin Ian King wrote:
> > On 05/09/13 10:33, Colin Ian King wrote:
> >> On 05/09/13 10:23, Evan Dandrea wrote:
> >>> Stuart Langridge brought up an interesting idea for this on IRC, which
> >>> I'm copying h
On 09/05/2013 12:42 PM, Colin Ian King wrote:
> On 05/09/13 10:33, Colin Ian King wrote:
>> On 05/09/13 10:23, Evan Dandrea wrote:
>>> Stuart Langridge brought up an interesting idea for this on IRC, which
>>> I'm copying here rather than having more side discussions:
[...]
Oops, I should have rea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/05/2013 12:28 AM, Steve Langasek wrote:
> I don't see any shortcuts around the fact that identifying runaway
> processes is going to require manually sifting through reports to
> identify possible problems. I think we should have a very clear
>
On 05/09/13 10:33, Colin Ian King wrote:
> On 05/09/13 10:23, Evan Dandrea wrote:
>> Stuart Langridge brought up an interesting idea for this on IRC, which
>> I'm copying here rather than having more side discussions:
>>
>> (10:13:20) aquarius: ev, just reading your thread about runaway
>> processe
On 05/09/13 10:23, Evan Dandrea wrote:
> Stuart Langridge brought up an interesting idea for this on IRC, which
> I'm copying here rather than having more side discussions:
>
> (10:13:20) aquarius: ev, just reading your thread about runaway
> processes on the touch mailing list (I'm not subscribed
Stuart Langridge brought up an interesting idea for this on IRC, which
I'm copying here rather than having more side discussions:
(10:13:20) aquarius: ev, just reading your thread about runaway
processes on the touch mailing list (I'm not subscribed to the list,
so there's no good way of replying)
Hi guys,
On Wed, Sep 04, 2013 at 04:06:33PM +0100, John Lea wrote:
> Hi All, two questions about the proposal below:
> 1) How do we differentiate between background non-ui processes that
> are legitimately using 100%+ of the CPU for extended periods of time
> and runaway processes?
This is inde
On Wed, 2013-09-04 at 11:32 -0700, Steve Langasek wrote:
> On Wed, Sep 04, 2013 at 01:16:07PM -0500, Ted Gould wrote:
> > I wasn't intending to say "upstart should do it" more that we should put
> > it in the Upstart job configuration and use that as our basis. That's
> > what I was trying to say
On Wed, Sep 04, 2013 at 01:16:07PM -0500, Ted Gould wrote:
> > On Wed, Sep 04, 2013 at 10:22:59AM -0500, Ted Gould wrote:
> > > To give people something to attack more specifically, I'll say this. We
> > > should add a line to Upstart job configs that looks like this:
> > > cpu limit [CPU
On Wed, Sep 4, 2013 at 5:06 PM, John Lea wrote:
> Hi All, two questions about the proposal below:
>
> 1) How do we differentiate between background non-ui processes that are
> legitimately using 100%+ of the CPU for extended periods of time and runaway
> processes?
>
> e.g. We have a photo panora
On Wed, 2013-09-04 at 11:01 -0700, Steve Langasek wrote:
> On Wed, Sep 04, 2013 at 10:22:59AM -0500, Ted Gould wrote:
> > It seems to me for all of these long running services the "manager" of
> > them is Upstart. It restarts them if they crash or do other stupid
> > things, and it knows whether
On Wed, Sep 04, 2013 at 10:22:59AM -0500, Ted Gould wrote:
> It seems to me for all of these long running services the "manager" of
> them is Upstart. It restarts them if they crash or do other stupid
> things, and it knows whether they're running. This seems roughly like
> respawn limits[1], whe
On 4 September 2013 16:22, Ted Gould wrote:
> We should probably start with reporting bugs, and then next step start
> killing. "Would have been killed" bugs might be an interesting metric :-)
Just to be pedantic: send error reports, not file bugs. Bugs can most
certainly be created from a probl
On 09/04/2013 05:49 AM, Evan Dandrea wrote:
> Hi folks,
>
> In another discussion, James Hunt raised the possibility of
> periodically checking for runaway processes on Touch, killing those
> consuming 100% CPU while creating a report to be sent to
> https://errors.ubuntu.com.
>
> I've summarised
On 4 September 2013 12:25, Thomas Voß wrote:
> +1, the respective grace/timeout period would need to be determined
> from empirical data, too.
Agreed.
>> With the application lifecycle work, background applications will be
>> suspended and get no CPU time at all, so this check will only apply to
Hi All, two questions about the proposal below:
1) How do we differentiate between background non-ui processes that are
legitimately using 100%+ of the CPU for extended periods of time and
runaway processes?
e.g. We have a photo panorama app. After a set of photos are taken, the
camera app
On 04/09/13 16:06, John Lea wrote:
> Hi All, two questions about the proposal below:
>
> 1) How do we differentiate between background non-ui processes that are
> legitimately using 100%+ of the CPU for extended periods of time and
> runaway processes?
Good question. Most resources are bounded
On Wed, 2013-09-04 at 14:35 +0100, Evan Dandrea wrote:
> On 4 September 2013 12:25, Thomas Voß wrote:
> > +1, the respective grace/timeout period would need to be determined
> > from empirical data, too.
>
> Agreed.
I think that it should also be per-service. For instance, HUD does the
voice
On Wed, Sep 4, 2013 at 2:04 PM, John Lenton wrote:
> On Wed, Sep 4, 2013 at 12:25 PM, Thomas Voß wrote:
>>
>> True, but to determine the CPU percentage, we would need to have the
>> CPU usage of all processes for a certain amount of time available.
>> That is, essentially parsing all of proc iiuc
On Wed, Sep 4, 2013 at 12:25 PM, Thomas Voß wrote:
>
> True, but to determine the CPU percentage, we would need to have the
> CPU usage of all processes for a certain amount of time available.
> That is, essentially parsing all of proc iiuc. I'm hopefully wrong,
> but if not, could we resort to an
hi,
On Mi, 2013-09-04 at 13:15 +0200, Alexander Sack wrote:
> > Note that this is not really about power consumption. Colin King has
> > done analysis of power consumption on Touch devices and the biggest
> > bang for the buck is ensuring that sensors are turned off when they
> > are not needed, n
Hey Evan,
thanks for the summary and for bringing up the topic. A few comments inline:
On Wed, Sep 4, 2013 at 11:49 AM, Evan Dandrea wrote:
> Hi folks,
>
> In another discussion, James Hunt raised the possibility of
> periodically checking for runaway processes on Touch, killing those
> consumin
On Wed, Sep 4, 2013 at 11:49 AM, Evan Dandrea wrote:
> Hi folks,
>
> In another discussion, James Hunt raised the possibility of
> periodically checking for runaway processes on Touch, killing those
> consuming 100% CPU while creating a report to be sent to
> https://errors.ubuntu.com.
>
> I've su
Hi folks,
In another discussion, James Hunt raised the possibility of
periodically checking for runaway processes on Touch, killing those
consuming 100% CPU while creating a report to be sent to
https://errors.ubuntu.com.
I've summarised the key points of that discussion here into a
proposal. The
34 matches
Mail list logo
