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

[Takenori Nagano]

MinChan Kim wrote:
> On Thu, Jun 26, 2008 at 2:24 PM, Takenori Nagano <t-nagano@xxxxxxxxxxxxx> wrote:
>> MinChan Kim wrote:
>>> On Thu, Jun 26, 2008 at 10:49 AM, Takenori Nagano
>>> <t-nagano@xxxxxxxxxxxxx> 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.

OK.
I'll try to test to make enough data. :-)

Thanks,
  Takenori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/