linux-kernel - Re: [RFC][PATCH] prevent incorrect oom under split

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Jun 2008 15:37:32 +0900
From:	"MinChan Kim" <minchan.kim@...il.com>
To:	"Takenori Nagano" <t-nagano@...jp.nec.com>
Cc:	"Peter Zijlstra" <peterz@...radead.org>,
	"KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com>,
	"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
Subject: Re: [RFC][PATCH] prevent incorrect oom under split_lru

On Thu, Jun 26, 2008 at 2:24 PM, Takenori Nagano <t-nagano@...jp.nec.com> wrote:
> MinChan Kim wrote:
>> On Thu, Jun 26, 2008 at 10:49 AM, Takenori Nagano
>> <t-nagano@...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 am not sure it will be a regression.
We don't have any enough data.

My intention is just to prevent kosaki-san's patch's corner case.

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



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