----- Original Message ----- > From: "Shuang Qiu" <[email protected]> > To: "Zhouping Liu" <[email protected]> > Cc: [email protected] > Sent: Monday, August 27, 2012 11:03:37 AM > Subject: Re: [LTP] [PATCH] Set tunable value of min_free_kbytes lower > > On 08/24/2012 09:48 PM, Zhouping Liu wrote: > > > > ----- Original Message ----- > >> From: "Shuang Qiu" <[email protected]> > >> To: "Zhouping Liu" <[email protected]> > >> Cc: [email protected] > >> Sent: Friday, August 24, 2012 6:18:00 PM > >> Subject: Re: [LTP] [PATCH] Set tunable value of min_free_kbytes > >> lower > >> > >> On 08/24/2012 04:11 PM, Zhouping Liu wrote: > >>> ----- Original Message ----- > >>>> From: "shuang qiu" <[email protected]> > >>>> To: [email protected] > >>>> Sent: Thursday, August 23, 2012 2:43:01 PM > >>>> Subject: [LTP] [PATCH] Set tunable value of min_free_kbytes > >>>> lower > >>>> > >>>> From: Shuang Qiu <[email protected]> > >>>> > >>>> The value of min_free_kbytes is set too high(half of mem_free) > >>>> during > >>>> testing min_free_kbytes tunable.It often cause the system to > >>>> become > >>>> out-of-memory.Using 20% of mem_free to avoid oom and system > >>>> hang. > >>> Hi, shuang > >>> > >>> I met the issue that min_free_kbytes caused system hang before, > >>> and > >>> what you said made sense. > >>> > >>> but after tested the patch, I found it still make the system hang > >>> with the patch, so I don't think > >>> this patch can fix the issue completely, maybe there are other > >>> factors, or need lower tune value. > >>> always suppose it was because of the high tune value, it's more > >>> better to add an optional to control it. > >>> also I will investigate it deeper to look after the real reason. > >>> please comment if you have other ideas. > >>> > >>> Thanks, > >>> Zhouping > >> Thanks for testing,Zhouping. > >> > >> I find it says "However, setting this parameter to a value that is > >> too > >> high (5-10% of total system memory) will cause your system to > >> become > >> out-of-memory immediately." in redhat memory-tunables document. > >> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-tunables.html > >> Set the value less than 5% of total memory will make it more safe. > > Thanks for sharing this! I will take your ideas into account. > > > >> Let's think about a better option to control it. > > Ok, I will prepare a patch for this. > > > > > >> It is great that you will investigate it deeper. > >> Seems there are some other problems in this case,it always failed > >> with i386. > >> The type of total_mem "unsigned long" is not suitable with > >> nowadays > >> memory ,it will overflow(with i386) in line 177:map_count = > >> total_mem > >> * > >> KB / MAP_SIZE and the value of map_count is not correct. > >> Using "unsigned long long" could fix this issue. > >> But the case still failed after fix it. > >> Could you help to investigate it too. > > sure. > >
Hi, Shuang I think the below patch can't fix the issue, it looks more like a bug related to oom-killer, I have opened a bug to trace it, please see https://bugzilla.redhat.com/show_bug.cgi?id=851938 > Hi Zhouping, > I think the reason for the failures which I met is also that it just > catched oom_killer scenario when overcommit_memory=1. > I found your patch before: > commit 4f267b6fd11749c91211c9dbfc706cf46919650b > Author: Zhouping Liu <[email protected]> > Date: Fri Mar 30 22:29:58 2012 +0800 > > mm/tunable: fix unexpected error log in min_free_kbytes > > when overcommit_memory=0, mmap() will be destroyed in two below > scenario: > 1) MAP_FAILED with ENOMEM, > 2) oom_killer kill it. > without the patch, it just catched oom_killer scenario, > the patch fixed it. > > > Could this patch also for when overcommit_memory=1 scenario? > > Thanks > Shuang > > > -- Thanks, Zhouping ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
