All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takenori Nagano <t-nagano@ah.jp.nec.com>
To: MinChan Kim <minchan.kim@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>, linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	akpm@linux-foundation.org
Subject: Re: [RFC][PATCH] prevent incorrect oom under split_lru
Date: Thu, 26 Jun 2008 14:24:09 +0900	[thread overview]
Message-ID: <486327F9.6030004@ah.jp.nec.com> (raw)
In-Reply-To: <28c262360806252137j78a90480n6c3973cd489c1ef2@mail.gmail.com>

MinChan Kim wrote:
> On Thu, Jun 26, 2008 at 10:49 AM, Takenori Nagano
> <t-nagano@ah.jp.nec.com> wrote:
>> MinChan Kim wrote:
>>> Hi peter,
>>>
>>> I agree with you.  but if application's virtual address space is big,
>>> we have a hard problem with mlockall since memory pressure might be a
>>> big.
>>> Of course, It will be a RT application design problem.
>>>
>>>> The much more important case is desktop usage - that is where we run non
>>>> real-time code, but do expect 'low' latency due to user-interaction.
>>>>
>>>> >From hitting swap on my 512M laptop (rather frequent occurance) I know
>>>> we can do better here,..
>>>>
>>> Absolutely. It is another example. So, I suggest following patch.
>>> It's based on idea of Takenori Nagano's memory reclaim more efficiently.
>> Hi Kim-san,
>>
>> Thank you for agreeing with me.
>>
>> I have one question.
>> My patch don't mind priority. Why do you need "priority == 0"?
> 
> Hi, Takenori-san.
> 
> Now, Kosaiki-san's patch didn't consider application latency.
> That patch scan all lru[x] pages when memory pressure is very high.
> (ie, priority == 0)
> It will cause application latency to high as peter and me notice that.
> We need a idea which prevent big scanning overhead
> I modified your idea to prevent big scanning overhead only when memory
> pressure is very big.

Hi, Kim-san.

Thank you for your explanation.
I understand your opinion.

But...your patch is not enough for me. :-(
Our Xeon box has 128GB memory, application latency will be very large if
priority goes to be zero.
So, I would like to use "cut off" on every priority.

I would like to delete "priority == 0", Can you?

Thanks,
  Takenori

WARNING: multiple messages have this Message-ID (diff)
From: Takenori Nagano <t-nagano@ah.jp.nec.com>
To: MinChan Kim <minchan.kim@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>, linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	akpm@linux-foundation.org
Subject: Re: [RFC][PATCH] prevent incorrect oom under split_lru
Date: Thu, 26 Jun 2008 14:24:09 +0900	[thread overview]
Message-ID: <486327F9.6030004@ah.jp.nec.com> (raw)
In-Reply-To: <28c262360806252137j78a90480n6c3973cd489c1ef2@mail.gmail.com>

MinChan Kim wrote:
> On Thu, Jun 26, 2008 at 10:49 AM, Takenori Nagano
> <t-nagano@ah.jp.nec.com> wrote:
>> MinChan Kim wrote:
>>> Hi peter,
>>>
>>> I agree with you.  but if application's virtual address space is big,
>>> we have a hard problem with mlockall since memory pressure might be a
>>> big.
>>> Of course, It will be a RT application design problem.
>>>
>>>> The much more important case is desktop usage - that is where we run non
>>>> real-time code, but do expect 'low' latency due to user-interaction.
>>>>
>>>> >From hitting swap on my 512M laptop (rather frequent occurance) I know
>>>> we can do better here,..
>>>>
>>> Absolutely. It is another example. So, I suggest following patch.
>>> It's based on idea of Takenori Nagano's memory reclaim more efficiently.
>> Hi Kim-san,
>>
>> Thank you for agreeing with me.
>>
>> I have one question.
>> My patch don't mind priority. Why do you need "priority == 0"?
> 
> Hi, Takenori-san.
> 
> Now, Kosaiki-san's patch didn't consider application latency.
> That patch scan all lru[x] pages when memory pressure is very high.
> (ie, priority == 0)
> It will cause application latency to high as peter and me notice that.
> We need a idea which prevent big scanning overhead
> I modified your idea to prevent big scanning overhead only when memory
> pressure is very big.

Hi, Kim-san.

Thank you for your explanation.
I understand your opinion.

But...your patch is not enough for me. :-(
Our Xeon box has 128GB memory, application latency will be very large if
priority goes to be zero.
So, I would like to use "cut off" on every priority.

I would like to delete "priority == 0", Can you?

Thanks,
  Takenori

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

  reply	other threads:[~2008-06-26  5:26 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-24  8:31 [RFC][PATCH] prevent incorrect oom under split_lru KOSAKI Motohiro
2008-06-24  8:31 ` KOSAKI Motohiro
2008-06-24 13:28 ` Rik van Riel
2008-06-24 13:28   ` Rik van Riel
2008-06-25  5:59   ` MinChan Kim
2008-06-25  5:59     ` MinChan Kim
2008-06-25  6:08     ` KOSAKI Motohiro
2008-06-25  6:08       ` KOSAKI Motohiro
2008-06-25  6:56       ` MinChan Kim
2008-06-25  6:56         ` MinChan Kim
2008-06-25  6:58         ` MinChan Kim
2008-06-25  6:58           ` MinChan Kim
2008-06-25  7:29           ` KOSAKI Motohiro
2008-06-25  7:29             ` KOSAKI Motohiro
2008-06-25  7:37             ` MinChan Kim
2008-06-25  7:37               ` MinChan Kim
2008-06-25 12:11         ` Peter Zijlstra
2008-06-25 12:11           ` Peter Zijlstra
2008-06-25 13:05           ` MinChan Kim
2008-06-25 13:05             ` MinChan Kim
2008-06-26  1:49             ` Takenori Nagano
2008-06-26  1:49               ` Takenori Nagano
2008-06-26  4:37               ` MinChan Kim
2008-06-26  4:37                 ` MinChan Kim
2008-06-26  5:24                 ` Takenori Nagano [this message]
2008-06-26  5:24                   ` Takenori Nagano
2008-06-26  6:37                   ` MinChan Kim
2008-06-26  6:37                     ` MinChan Kim
2008-06-26  8:05                     ` Takenori Nagano
2008-06-26  8:05                       ` Takenori Nagano
2008-06-26  0:36           ` KOSAKI Motohiro
2008-06-26  0:36             ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=486327F9.6030004@ah.jp.nec.com \
    --to=t-nagano@ah.jp.nec.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan.kim@gmail.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.