Messages in this thread | | | Date | Wed, 25 Jun 2008 15:58:26 +0900 | From | "MinChan Kim" <> | Subject | Re: [RFC][PATCH] prevent incorrect oom under split_lru |
| |
On Wed, Jun 25, 2008 at 3:56 PM, MinChan Kim <minchan.kim@gmail.com> wrote: > 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
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
| |