[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28c262360806250037k9fcde73g9b28c26eb8523f04@mail.gmail.com>
Date: Wed, 25 Jun 2008 16:37:29 +0900
From: "MinChan Kim" <minchan.kim@...il.com>
To: "KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com>
Cc: "Rik van Riel" <riel@...hat.com>, linux-mm <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
"Lee Schermerhorn" <Lee.Schermerhorn@...com>,
akpm@...ux-foundation.org,
"Takenori Nagano" <t-nagano@...jp.nec.com>
Subject: Re: [RFC][PATCH] prevent incorrect oom under split_lru
On Wed, Jun 25, 2008 at 4:29 PM, KOSAKI Motohiro
<kosaki.motohiro@...fujitsu.com> wrote:
>> > 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.
>
> Yup.
> Agreed with latency is as important as throughput.
>
> if anyone explain that patch have reduce some latency and
> no throughput degression by benchmark result,
> I have no objection, Of cource.
>
> Can you post any performance result?
>
>
hm.. I am not sure when I can post result of benchmark.
Of course, If I do, I will post it :)
Thanks, Kosaki-san
--
Kinds regards,
MinChan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists