From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755458Ab1JKTUw (ORCPT ); Tue, 11 Oct 2011 15:20:52 -0400 Received: from usindpps03.hds.com ([207.126.252.16]:41235 "EHLO usindpps03.hds.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755356Ab1JKTUp convert rfc822-to-8bit (ORCPT ); Tue, 11 Oct 2011 15:20:45 -0400 From: Satoru Moriya To: David Rientjes , Rik van Riel CC: Randy Dunlap , Satoru Moriya , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "lwoodman@redhat.com" , Seiji Aguchi , "akpm@linux-foundation.org" , "hughd@google.com" , "hannes@cmpxchg.org" Date: Tue, 11 Oct 2011 15:20:14 -0400 Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable Thread-Topic: [PATCH -v2 -mm] add extra free kbytes tunable Thread-Index: AcyFZ5CbDfuWvVnPRqCPUu/MZXTaewC4sTqA Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB516CBBC@USINDEVS02.corp.hds.com> References: <20110901105208.3849a8ff@annuminas.surriel.com> <20110901100650.6d884589.rdunlap@xenotime.net> <20110901152650.7a63cb8b@annuminas.surriel.com> In-Reply-To: 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=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110110223 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/07/2011 11:08 PM, David Rientjes wrote: > On Thu, 1 Sep 2011, Rik van Riel wrote: > > I also > think that it will cause regressions on other cpu intensive workloads > that don't require this extra freed memory because it works as a > global heuristic and is not tied to any specific application. It's yes and no. It may cause regressions on the workloads due to less amount of available memory. But it may improve the workloads' performance because they can avoid direct reclaim due to extra free memory. Of course if one doesn't need extra free memory, one can turn it off. I think we can add this feature to cgroup if we want to set it for any specific process or process group. (Before that we need to implement min_free_kbytes for cgroup and the implementation of extra free kbytes strongly depends on it.) > I think it would be far better to reclaim beyond above the high > watermark if the types of workloads that need this tunable can be > somehow detected (the worst case scenario is being a prctl() that does > synchronous reclaim above the watermark so admins can identify these > workloads), or be able to mark allocations within the kernel as > potentially coming in large bursts where allocation is problematic. It may work. But isn't it difficult and/or complex to decide how much memory we should reclaim beyond high watermark automatically? I believe that extra free kbytes is far simpler than them. Regards, Satoru From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail6.bemta12.messagelabs.com (mail6.bemta12.messagelabs.com [216.82.250.247]) by kanga.kvack.org (Postfix) with ESMTP id E0DA66B002D for ; Tue, 11 Oct 2011 15:20:37 -0400 (EDT) From: Satoru Moriya Date: Tue, 11 Oct 2011 15:20:14 -0400 Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable Message-ID: <65795E11DBF1E645A09CEC7EAEE94B9CB516CBBC@USINDEVS02.corp.hds.com> References: <20110901105208.3849a8ff@annuminas.surriel.com> <20110901100650.6d884589.rdunlap@xenotime.net> <20110901152650.7a63cb8b@annuminas.surriel.com> In-Reply-To: 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: David Rientjes , Rik van Riel Cc: Randy Dunlap , Satoru Moriya , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "lwoodman@redhat.com" , Seiji Aguchi , "akpm@linux-foundation.org" , "hughd@google.com" , "hannes@cmpxchg.org" On 10/07/2011 11:08 PM, David Rientjes wrote: > On Thu, 1 Sep 2011, Rik van Riel wrote: > > I also > think that it will cause regressions on other cpu intensive workloads=20 > that don't require this extra freed memory because it works as a=20 > global heuristic and is not tied to any specific application. It's yes and no. It may cause regressions on the workloads due to less amount of available memory. But it may improve the workloads' performance because they can avoid direct reclaim due to extra free memory. Of course if one doesn't need extra free memory, one can turn it off. I think we can add this feature to cgroup if we want to set it for any specific process or process group. (Before that we need to implement min_free_kbytes for cgroup and the implementation of extra free kbytes strongly depends on it.) > I think it would be far better to reclaim beyond above the high=20 > watermark if the types of workloads that need this tunable can be=20 > somehow detected (the worst case scenario is being a prctl() that does=20 > synchronous reclaim above the watermark so admins can identify these=20 > workloads), or be able to mark allocations within the kernel as=20 > potentially coming in large bursts where allocation is problematic. It may work. But isn't it difficult and/or complex to decide how much memory we should reclaim beyond high watermark automatically? I believe that extra free kbytes is far simpler than them. 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