ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 07/29/2015 11:09 AM, Tyler Hicks wrote:
> On 2015-07-29 11:25:27, Alberto Mardegan wrote:
>> On 07/29/2015 07:07 AM, Tyler Hicks wrote:

>>> The exec() will need to occur after special process initialization
>>> such as setting rlimits, configuring cgroups, etc., but before
>>> attempting to preload any libraries.
>>>
>>> I've prototyped the difference with a simple proof-of-concept of a 
>>> booster daemon and app program and the exec() slows down things a 
>>> considerable amount. Any benchmarks should definitely include such
>>> a change in order to not get any hopes up by looking at the
>>> non-exec()ing benchmark numbers.
>>
>> But the exec() does not necessarily need to load the application,
>> right? It could happen when the user has not yet chosen which
>> application to start, and instead of executing an app, it could exec()
>> into a loader process which does all library preloading and
>> initializing, and then (when the user launches an app) dlopen the app,
>> close any unneeded file descriptors, call aa_change_profile and
>> finally run main(). Then of course it would have to quit, and not be
>> reused.
> 
> Yes, exactly!
> 
>> This would still preserve the ASLR, wouldn't it?
> 
> Yes. I think there will still be plenty of speed benefits. I don't think
> the memory footprint benefits of the booster processes will be nearly as
> good, though. My whole point is that it is worth benchmarking because I
> think we'll still good performance.
> 
I think it is important to note (and please correct me if I am wrong! :) that,
today, there is no memory footprint benefit to lose because, today, we have a
full fork/exec of each app. Therefore if we can realize 'plenty of speed
benefits' as Tyler believes we can (and that people should benchmark), that is a
complete 'win' for the platform.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature