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

["MinChan Kim" <minchan.kim@gmail.com>]

On Wed, Jun 25, 2008 at 3:08 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> 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

>> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>