Re: [RFC][PATCH] prevent incorrect oom under split_lru

[MinChan Kim]

On Wed, Jun 25, 2008 at 3:56 PM, MinChan Kim <minchan.kim@xxxxxxxxx> wrote:
> On Wed, Jun 25, 2008 at 3:08 PM, KOSAKI Motohiro
> <kosaki.motohiro@xxxxxxxxxxxxxx> wrote:
>> Hi Kim-san,
>>
>>> >> So, if priority==0, We should try to reclaim all page for prevent OOM.
>>> >
>>> > You are absolutely right.  Good catch.
>>>
>>> I have a concern about application latency.
>>> If lru list have many pages, it take a very long time to scan pages.
>>> More system have many ram, More many time to scan pages.
>>
>> No problem.
>>
>> priority==0 indicate emergency.
>> it doesn't happend on typical workload.
>>
>
> I see :)
>
> But if such emergency happen in embedded system, application can't be
> executed for some time.
> I am not sure how long time it take.
> But In some application, schedule period is very important than memory
> reclaim latency.
>
> Now, In your patch, when such emergency happen, it continue to reclaim
> page until it will scan entire page of lru list.
> It

with my mistake, I omit following message. :(

So, we need cut-off mechanism to reduce application latency.
So In my opinion, If we modify some code of Takenori's patch, we can
apply his idea to prevent latency probelm.

>>> Of course I know this is trade-off between memory efficiency VS latency.
>>> But In embedded, some application think latency is more important
>>> thing than memory efficiency.
>>> We need some mechanism to cut off scanning time.
>>>
>>> I think Takenori Nagano's "memory reclaim more efficiently patch" is
>>> proper to reduce application latency in this case If we modify some
>>> code.
>>
>> I think this is off-topic.
>>
>> but Yes.
>> both my page reclaim throttle and nagano-san's patch provide
>> reclaim cut off mechanism.
>>
>>
>> and more off-topic,
>> nagano-san's patch improve only priority==12.
>> So, typical embedded doesn't improve so big because
>> embedded system does't have so large memory.
>>
>>
>>
>>
>
>
>
> --
> Kinds regards,
> MinChan Kim
>



-- 
Kinds regards,
MinChan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/