From: Satoru Moriya <satoru.moriya@hds.com> To: David Rientjes <rientjes@google.com>, Con Kolivas <kernel@kolivas.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Rik van Riel <riel@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>, Satoru Moriya <smoriya@redhat.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "lwoodman@redhat.com" <lwoodman@redhat.com>, Seiji Aguchi <saguchi@redhat.com>, Hugh Dickins <hughd@google.com>, "hannes@cmpxchg.org" <hannes@cmpxchg.org> Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable Date: Thu, 13 Oct 2011 12:54:40 -0400 [thread overview] Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB516D459@USINDEVS02.corp.hds.com> (raw) In-Reply-To: <alpine.DEB.2.00.1110111612120.5236@chino.kir.corp.google.com> On 10/11/2011 07:22 PM, David Rientjes wrote: > On Tue, 11 Oct 2011, Satoru Moriya wrote: > > I don't know if your test case is the only thing that Rik is looking > at, but if so, then that statement makes me believe that this patch is > definitely in the wrong direction, so NACK on it until additional > information is presented. The reasoning is simple: if tuning the > bonus given to rt-tasks in the page allocator itself would fix the > issue, then we can certainly add logic specifically for rt-tasks that > can reclaim more aggressively without needing any tunable from > userspace (and _certainly_ not a global tunable that affects every application!). My test case is just a simple one (maybe too simple), and I tried to demonstrate following issues that current kernel has with it. 1. Current kernel uses free memory as pagecache. 2. Applications may allocate memory burstly and when it happens they may get a latency issue because there are not enough free memory. Also the amount of required memory is wide-ranging. 3. Some users would like to control the amount of free memory to avoid the situation above. 4. User can't setup the amount of free memory explicitly. From user's point of view, the amount of free memory is the delta between high watermark - min watermark because below min watermark user applications incur a penalty (direct reclaim). The width of delta depends on min_free_kbytes, actually min watermark / 2, and so if we want to make free memory bigger, we must make min_free_kbytes bigger. It's not a intuitive and it introduces another problem that is possibility of direct reclaim is increased. I think my test case is too simple and so we may be able to avoid the latency issue with my case by setting the workload rt-task, improving how to decide rt-task bonus and/or introducing the Con's patches below. But my concern described above is still alive because whether latency issue happen or not depends on how heavily workloads allocate memory at a short time. Of cource we can say same things for extra_free_kbytes, but we can change it and test an effect easily. >>> Does there exist anything like a test case which demonstrates the >>> need for this feature? >> >> Unfortunately I don't have a real test case but just simple one. >> And in my simple test case, I can avoid direct reclaim if we set >> workload as rt-task. >> >> The simple test case I used is following: >> http://marc.info/?l=linux-mm&m=131605773321672&w=2 >> > > I tried proposing one of Con's patches from his BFS scheduler ("mm: > adjust kswapd nice level for high priority page") about 1 1/2 years > ago that I recall and believe may significantly help your test case. > The thread is at http://marc.info/?t=126743860700002. (There's a lot > of interesting things in Con's patchset that can be pulled into the > VM, this isn't the only one.) > > The patch wasn't merged back then because we wanted a test case that > was specifically fixed by this issue, and it may be that we have just > found one. If you could try it out without any extra_free_kbytes, I > think we may be able to help your situation. Thank you, David. I'll try my simple workload with it. Regards, Satoru
WARNING: multiple messages have this Message-ID (diff)
From: Satoru Moriya <satoru.moriya@hds.com> To: David Rientjes <rientjes@google.com>, Con Kolivas <kernel@kolivas.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Rik van Riel <riel@redhat.com>, Randy Dunlap <rdunlap@xenotime.net>, Satoru Moriya <smoriya@redhat.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "lwoodman@redhat.com" <lwoodman@redhat.com>, Seiji Aguchi <saguchi@redhat.com>, Hugh Dickins <hughd@google.com>, "hannes@cmpxchg.org" <hannes@cmpxchg.org> Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable Date: Thu, 13 Oct 2011 12:54:40 -0400 [thread overview] Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB516D459@USINDEVS02.corp.hds.com> (raw) In-Reply-To: <alpine.DEB.2.00.1110111612120.5236@chino.kir.corp.google.com> On 10/11/2011 07:22 PM, David Rientjes wrote: > On Tue, 11 Oct 2011, Satoru Moriya wrote: > > I don't know if your test case is the only thing that Rik is looking > at, but if so, then that statement makes me believe that this patch is > definitely in the wrong direction, so NACK on it until additional > information is presented. The reasoning is simple: if tuning the > bonus given to rt-tasks in the page allocator itself would fix the > issue, then we can certainly add logic specifically for rt-tasks that > can reclaim more aggressively without needing any tunable from > userspace (and _certainly_ not a global tunable that affects every application!). My test case is just a simple one (maybe too simple), and I tried to demonstrate following issues that current kernel has with it. 1. Current kernel uses free memory as pagecache. 2. Applications may allocate memory burstly and when it happens they may get a latency issue because there are not enough free memory. Also the amount of required memory is wide-ranging. 3. Some users would like to control the amount of free memory to avoid the situation above. 4. User can't setup the amount of free memory explicitly. From user's point of view, the amount of free memory is the delta between high watermark - min watermark because below min watermark user applications incur a penalty (direct reclaim). The width of delta depends on min_free_kbytes, actually min watermark / 2, and so if we want to make free memory bigger, we must make min_free_kbytes bigger. It's not a intuitive and it introduces another problem that is possibility of direct reclaim is increased. I think my test case is too simple and so we may be able to avoid the latency issue with my case by setting the workload rt-task, improving how to decide rt-task bonus and/or introducing the Con's patches below. But my concern described above is still alive because whether latency issue happen or not depends on how heavily workloads allocate memory at a short time. Of cource we can say same things for extra_free_kbytes, but we can change it and test an effect easily. >>> Does there exist anything like a test case which demonstrates the >>> need for this feature? >> >> Unfortunately I don't have a real test case but just simple one. >> And in my simple test case, I can avoid direct reclaim if we set >> workload as rt-task. >> >> The simple test case I used is following: >> http://marc.info/?l=linux-mm&m=131605773321672&w=2 >> > > I tried proposing one of Con's patches from his BFS scheduler ("mm: > adjust kswapd nice level for high priority page") about 1 1/2 years > ago that I recall and believe may significantly help your test case. > The thread is at http://marc.info/?t=126743860700002. (There's a lot > of interesting things in Con's patchset that can be pulled into the > VM, this isn't the only one.) > > The patch wasn't merged back then because we wanted a test case that > was specifically fixed by this issue, and it may be that we have just > found one. If you could try it out without any extra_free_kbytes, I > think we may be able to help your situation. Thank you, David. I'll try my simple workload with it. Regards, Satoru -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-10-13 16:55 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-09-01 14:52 [PATCH -mm] add extra free kbytes tunable Rik van Riel 2011-09-01 14:52 ` Rik van Riel 2011-09-01 17:06 ` Randy Dunlap 2011-09-01 17:06 ` Randy Dunlap 2011-09-01 19:26 ` [PATCH -v2 " Rik van Riel 2011-09-01 19:26 ` Rik van Riel 2011-09-01 21:58 ` Andrew Morton 2011-09-01 21:58 ` Andrew Morton 2011-09-01 22:08 ` David Rientjes 2011-09-01 22:08 ` David Rientjes 2011-09-01 22:16 ` Andrew Morton 2011-09-01 22:16 ` Andrew Morton 2011-09-02 16:31 ` Satoru Moriya 2011-09-02 16:31 ` Satoru Moriya 2011-10-13 7:33 ` Minchan Kim 2011-10-13 7:33 ` Minchan Kim 2011-10-13 8:09 ` KAMEZAWA Hiroyuki 2011-10-13 8:09 ` KAMEZAWA Hiroyuki [not found] ` <E1FA588BC672D846BDBB452FCA1E308C2389B4@USINDEVS02.corp.hds.com> 2011-09-15 3:33 ` Satoru Moriya 2011-09-15 3:33 ` Satoru Moriya 2011-09-01 22:09 ` Andrew Morton 2011-09-01 22:09 ` Andrew Morton 2011-09-02 16:26 ` [PATCH -mm] fixes & cleanups for "add extra free kbytes tunable" Rik van Riel 2011-09-02 16:26 ` Rik van Riel 2011-09-30 21:43 ` [PATCH -v2 -mm] add extra free kbytes tunable Johannes Weiner 2011-09-30 21:43 ` Johannes Weiner 2011-10-08 3:08 ` David Rientjes 2011-10-08 3:08 ` David Rientjes 2011-10-10 22:37 ` Andrew Morton 2011-10-10 22:37 ` Andrew Morton 2011-10-11 19:32 ` Satoru Moriya 2011-10-11 19:32 ` Satoru Moriya 2011-10-11 19:54 ` Andrew Morton 2011-10-11 19:54 ` Andrew Morton 2011-10-11 20:23 ` Satoru Moriya 2011-10-11 20:23 ` Satoru Moriya 2011-10-11 20:54 ` Andrew Morton 2011-10-11 20:54 ` Andrew Morton 2011-10-12 13:09 ` Rik van Riel 2011-10-12 13:09 ` Rik van Riel 2011-10-12 19:20 ` Andrew Morton 2011-10-12 19:20 ` Andrew Morton 2011-10-12 19:58 ` Rik van Riel 2011-10-12 19:58 ` Rik van Riel 2011-10-12 20:26 ` David Rientjes 2011-10-12 20:26 ` David Rientjes 2011-10-21 23:48 ` Satoru Moriya 2011-10-21 23:48 ` Satoru Moriya 2011-10-23 21:22 ` David Rientjes 2011-10-23 21:22 ` David Rientjes 2011-10-25 2:04 ` Satoru Moriya 2011-10-25 2:04 ` Satoru Moriya 2011-10-25 21:50 ` David Rientjes 2011-10-25 21:50 ` David Rientjes 2011-10-26 18:59 ` Satoru Moriya 2011-10-26 18:59 ` Satoru Moriya 2011-10-12 21:08 ` Satoru Moriya 2011-10-12 21:08 ` Satoru Moriya 2011-10-12 22:41 ` David Rientjes 2011-10-12 22:41 ` David Rientjes 2011-10-12 23:52 ` Satoru Moriya 2011-10-12 23:52 ` Satoru Moriya 2011-10-13 0:01 ` David Rientjes 2011-10-13 0:01 ` David Rientjes 2011-10-13 5:35 ` KAMEZAWA Hiroyuki 2011-10-13 5:35 ` KAMEZAWA Hiroyuki 2011-10-13 20:55 ` David Rientjes 2011-10-13 20:55 ` David Rientjes 2011-10-14 22:16 ` Satoru Moriya 2011-10-14 22:16 ` Satoru Moriya 2011-10-14 22:46 ` David Rientjes 2011-10-14 22:46 ` David Rientjes 2011-10-14 5:32 ` Satoru Moriya 2011-10-14 5:32 ` Satoru Moriya 2011-10-14 5:06 ` Satoru Moriya 2011-10-14 5:06 ` Satoru Moriya 2011-10-11 23:22 ` David Rientjes 2011-10-11 23:22 ` David Rientjes 2011-10-13 16:54 ` Satoru Moriya [this message] 2011-10-13 16:54 ` Satoru Moriya 2011-10-13 20:48 ` David Rientjes 2011-10-13 20:48 ` David Rientjes 2011-10-13 21:11 ` Rik van Riel 2011-10-13 21:11 ` Rik van Riel 2011-10-13 22:02 ` David Rientjes 2011-10-13 22:02 ` David Rientjes 2011-10-11 19:20 ` Satoru Moriya 2011-10-11 19:20 ` Satoru Moriya 2011-10-11 21:04 ` David Rientjes 2011-10-11 21:04 ` David Rientjes 2011-10-12 13:13 ` Rik van Riel 2011-10-12 13:13 ` Rik van Riel 2011-10-12 20:21 ` David Rientjes 2011-10-12 20:21 ` David Rientjes 2011-10-13 4:13 ` Rik van Riel 2011-10-13 4:13 ` Rik van Riel 2011-10-13 5:22 ` David Rientjes 2011-10-13 5:22 ` David Rientjes 2011-10-22 0:11 ` Satoru Moriya 2011-10-22 0:11 ` Satoru Moriya 2011-09-09 23:01 Satoru Moriya 2011-09-09 23:01 ` Satoru Moriya
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=65795E11DBF1E645A09CEC7EAEE94B9CB516D459@USINDEVS02.corp.hds.com \ --to=satoru.moriya@hds.com \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=kernel@kolivas.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lwoodman@redhat.com \ --cc=rdunlap@xenotime.net \ --cc=riel@redhat.com \ --cc=rientjes@google.com \ --cc=saguchi@redhat.com \ --cc=smoriya@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: linkBe 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.