Trying to reduce our memory and battery footprint

[Ted Gould]

On Tue, 2012-10-16 at 09:59 +0100, James Hunt wrote:
> On 15/10/12 21:23, Ted Gould wrote:
> > On Mon, 2012-10-15 at 21:19 +0200, Sebastien Bacher wrote:
> >> Le 15/10/2012 21:10, Ted Gould a écrit :
> >>> I don't believe that
> >>> happened in the Q cycle, do we think that we could get upstart
> >>
> >> James pinged me recently because foundation is planning work for next 
> >> cycle and wanted to know what's the most important on the list for 
> >> desktop. I said it would be "user session jobs", do other still agree 
> >> with that? If you have other request I think there is still time at UDS 
> >> to discuss those
> > 
> > I still don't understand why we want a single upstart instance and not
> > one system one and one per session.  I think that having a single
> > instance is what makes user jobs difficult as you have to handle all the
> > states of things like encrypted file systems, where if we started the
> > upstart process later, PAM/lightdm would do it for us.  There are other
> > benefits too, but at least if I can move that out of the way I can get
> > other features :-)
>
> The current thinking is in fact to have 1 process / user. I think Scott
> was suggesting that everything _can_ be handled by PID 1, but whilst
> that may be technically true, my view is that the benefits of 1 process
> / user outweigh having PID 1 handle everything. It would make sense to
> add in user job logging with enhanced user session support. I already
> have a branch for this which went through a number of iterations to
> ensure that the facility was safe, secure and fast. The only way that
> all those requirements can be satisfied from my findings is to have a
> user process handle user job logging. So this fits in with the overall
> thinking on upstart user sessions too.

Great!  I think that makes a lot of sense.  I think it also means that
we can do additional AppArmor isolations that we couldn't do on PID 1.

So then can we really early (right now) rearrange the desktop startup to
start upstart when then start dbus and gnome-session?  That would give
us the ability to start migrating jobs over to being upstart user jobs
over time without having to do all at once (like we have done with SysV
Init jobs in system startup).  I'm sure when we do this at first it'll
cause some regressions with things like a11y, but if we start early we
can fix them by release time.

It would also be nice to get the user upstart as the DBus activation
broker on the session bus.  That way "it knows all" ;-)
 
> > The feature that upstart doesn't have today that I think would help the
> > most on the power/memory front is file watches.  That way processes that
> > watch a set of files for some change, could just be started when that
> > change happens, deal with it, and then shut themselves down.
>
> Agreed. Again, I have a basic 'upstart-file-bridge' in development.
> However, there are a quite a few issues that need to be dealt for such a
> bridge to work reliably. One of the "biggies" is supporting recursive
> watches explicitly, or atleast internally to minimise the risk of
> possible fd-starvation. The first issue though is finding a suitable API
> to use:
<snip>

I guess what I care about is that we provide a way to specify it in the
job definition, if upstart does it a hacky way to get it bootstrapped
that's fine.  We can move from doing the shell based to an *notify based
solution internally over time.  I just want to start defining jobs and
killing long running processes.

> > Second for me would be DConf key watches.  It is hard today to have
> > something start when a key is set to "True" to enable a feature.
> > Usually there has to be some sort of framework involved or a process has
> > to sit around waiting to be enabled.
>
> Yes, and a D-Bus bridge might be useful too? In fact a modular bridge
> design might be even better. Again, you could just do:
> 
>  dconf watch | initctl emit dconf DPATH=/desktop/unity/foo

Again, same as above, if we could hide that from the task definition
that would be fine IMHO.  We should also look to see if we can have
dconf help here, since we are paying the maintainer to work on it...

		--Ted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-desktop/attachments/20121016/22ca1bd1/attachment.pgp>