From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755358Ab1JKTfm (ORCPT ); Tue, 11 Oct 2011 15:35:42 -0400 Received: from usindpps06.hds.com ([207.126.252.19]:46359 "EHLO usindpps06.hds.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754933Ab1JKTfl convert rfc822-to-8bit (ORCPT ); Tue, 11 Oct 2011 15:35:41 -0400 From: Satoru Moriya To: Andrew Morton , David Rientjes CC: Rik van Riel , Randy Dunlap , Satoru Moriya , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "lwoodman@redhat.com" , Seiji Aguchi , "hughd@google.com" , "hannes@cmpxchg.org" Date: Tue, 11 Oct 2011 15:32:11 -0400 Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable Thread-Topic: [PATCH -v2 -mm] add extra free kbytes tunable Thread-Index: AcyHnTfmFReYnxFBTPGiWHi2BA2a6wAraVyg Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB516CBC4@USINDEVS02.corp.hds.com> References: <20110901105208.3849a8ff@annuminas.surriel.com> <20110901100650.6d884589.rdunlap@xenotime.net> <20110901152650.7a63cb8b@annuminas.surriel.com> <20111010153723.6397924f.akpm@linux-foundation.org> In-Reply-To: <20111010153723.6397924f.akpm@linux-foundation.org> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 ipscore=0 suspectscore=34 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110110228 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/10/2011 06:37 PM, Andrew Morton wrote: > On Fri, 7 Oct 2011 20:08:19 -0700 (PDT) David Rientjes > wrote: > >> On Thu, 1 Sep 2011, Rik van Riel wrote: > > The page allocator already tries harder if the caller has > rt_task(current). Why is this inadequate? Can we extend this idea > further to fix whatever-the-problem-is? Actually page allocator decreases min watermark to 3/4 * min watermark for rt-task. But in our case some applications create a lot of processes and if all of them are rt-task, the amount of watermark bonus(1/4 * min watermark) is not enough. If we can tune the amount of bonus, it may be fine. But that is almost all same as extra free kbytes. > 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 Regards, Satoru From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with ESMTP id 487846B002D for ; Tue, 11 Oct 2011 15:35:35 -0400 (EDT) From: Satoru Moriya Date: Tue, 11 Oct 2011 15:32:11 -0400 Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB516CBC4@USINDEVS02.corp.hds.com> References: <20110901105208.3849a8ff@annuminas.surriel.com> <20110901100650.6d884589.rdunlap@xenotime.net> <20110901152650.7a63cb8b@annuminas.surriel.com> <20111010153723.6397924f.akpm@linux-foundation.org> In-Reply-To: <20111010153723.6397924f.akpm@linux-foundation.org> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton , David Rientjes Cc: Rik van Riel , Randy Dunlap , Satoru Moriya , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "lwoodman@redhat.com" , Seiji Aguchi , "hughd@google.com" , "hannes@cmpxchg.org" On 10/10/2011 06:37 PM, Andrew Morton wrote: > On Fri, 7 Oct 2011 20:08:19 -0700 (PDT) David Rientjes=20 > wrote: >=20 >> On Thu, 1 Sep 2011, Rik van Riel wrote: > > The page allocator already tries harder if the caller has=20 > rt_task(current). Why is this inadequate? Can we extend this idea=20 > further to fix whatever-the-problem-is? Actually page allocator decreases min watermark to 3/4 * min watermark for rt-task. But in our case some applications create a lot of processes and if all of them are rt-task, the amount of watermark bonus(1/4 * min watermark) is not enough. If we can tune the amount of bonus, it may be fine. But that is almost all same as extra free kbytes. > Does there exist anything like a test case which demonstrates the need=20 > 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=3Dlinux-mm&m=3D131605773321672&w=3D2 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: email@kvack.org