Ohh, I was expecting oom_adj to have more restrictions, I didn't
expect it to be writeable by the process.

So it looks like the case is that pretty much any application can just do

echo "-17" > /proc/(mypid)/oom_adj

and be unkillable by the oom killer, right, and that's what the
original poster should do for their
ril/tty app?


On Wed, Feb 16, 2011 at 8:26 PM, Dianne Hackborn <[email protected]> wrote:
> The oom_adj set for the process is what determines when the oom killer will
> kill it.  Values < 0 are killed after *all* application processes.
>
> On Wed, Feb 16, 2011 at 7:42 AM, AppCoder <[email protected]> wrote:
>>
>>
>> On Feb 15, 7:44 pm, Dianne Hackborn <[email protected]> wrote:
>> > No, it is not, it is done by the OOM killer in the kernel.  It decides
>> > what
>> > to kill first based on the oom_adj, with higher numbers killed before
>> > lower
>> > ones.  The foreground process is oom_adj 0, the least needed process is
>> > 16,
>> > system processes are < 0.
>>
>> Too much unix on the brain.   I imagined that a process which made
>> ttys available
>> to the rild from init.rc to not have to do any interactions with the
>> android service
>> architecture.
>>
>> What would a native arm binary have to do to be considered a system
>> process
>> when started from init.rc? (I get that android:persistent set to true
>> in the
>> manifest probably does it for things with a manifest.)
>>
>> Given that one of those two things happens, is it safe to say such a
>> process
>> is only in competition with other init processes and anything with
>> android:persistent
>> set to true in it's manifest (and the original poster doesn't need to
>> worry about some
>> app getting their native service killed)?
>>
>> --
>> unsubscribe: [email protected]
>> website: http://groups.google.com/group/android-porting
>
>
>
> --
> Dianne Hackborn
> Android framework engineer
> [email protected]
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails.  All such
> questions should be posted on public forums, where I and others can see and
> answer them.
>
>

-- 
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting

Reply via email to