Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755435AbaDQKlm (ORCPT ); Thu, 17 Apr 2014 06:41:42 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:51564 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752149AbaDQKlj (ORCPT ); Thu, 17 Apr 2014 06:41:39 -0400 MIME-Version: 1.0 In-Reply-To: <20140416154631.6d0173498c60619d454ae651@linux-foundation.org> References: <1396235199.2507.2.camel@buesod1.americas.hpqcorp.net> <20140331161308.6510381345cb9a1b419d5ec0@linux-foundation.org> <1396308332.18499.25.camel@buesod1.americas.hpqcorp.net> <20140331170546.3b3e72f0.akpm@linux-foundation.org> <1396371699.25314.11.camel@buesod1.americas.hpqcorp.net> <1396377083.25314.17.camel@buesod1.americas.hpqcorp.net> <1396386062.25314.24.camel@buesod1.americas.hpqcorp.net> <20140401142947.927642a408d84df27d581e36@linux-foundation.org> <20140401144801.603c288674ab8f417b42a043@linux-foundation.org> <1396389751.25314.26.camel@buesod1.americas.hpqcorp.net> <20140401150843.13da3743554ad541629c936d@linux-foundation.org> <534AD1EE.3050705@colorfullife.com> <20140416154631.6d0173498c60619d454ae651@linux-foundation.org> From: Michael Kerrisk Date: Thu, 17 Apr 2014 12:41:18 +0200 X-Google-Sender-Auth: Btiy0tWkJZHI_V3kOPSqISyk4iM Message-ID: Subject: Re: [PATCH] ipc,shm: increase default size for shmmax To: Andrew Morton Cc: Manfred Spraul , Davidlohr Bueso , KOSAKI Motohiro , aswin@hp.com, LKML , "linux-mm@kvack.org" , Michael Kerrisk-manpages Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 17, 2014 at 12:46 AM, Andrew Morton wrote: > On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul wrote: > >> Hi Andrew, >> >> On 04/02/2014 12:08 AM, Andrew Morton wrote: >> > Well, I'm assuming 64GB==infinity. It *was* infinity in the RHEL5 >> > timeframe, but infinity has since become larger so pickanumber. >> >> I think infinity is the right solution: >> The only common case where infinity is wrong would be Android - and >> Android disables sysv shm entirely. >> >> There are two patches: >> http://marc.info/?l=linux-kernel&m=139730332306185&q=raw >> http://marc.info/?l=linux-kernel&m=139727299800644&q=raw >> >> Could you apply one of them? >> I wrote the first one, thus I'm biased which one is better. > > I like your patch because applying it might encourage you to send more > kernel patches - I miss the old days ;) > > But I do worry about disrupting existing systems so I like Davidlohr's > idea of making the change a no-op for people who are currently > explicitly setting shmmax and shmall. Agreed. It's hard to imagine situations where people might care nowadays, but there's no limits to people's insane inventiveness. Some people really might want to set an upper limit. > In an ideal world, system administrators would review this change, And in the ideal world, patches such as this would CC linux-api@vger.kernel.org, as described in Documentation/SubmitChecklist, so that users who care about getting advance warning on API changes could be alerted and might even review and comment... > would remove their explicit limit-setting and would retest everything > then roll it out. But in the real world with Davidlohr's patch, they > just won't know that we did this and they'll still be manually > configuring shmmax/shmall ten years from now. I almost wonder if we > should drop a printk_once("hey, you don't need to do that any more") > when shmmax/shmall are altered? Makes some sense. But then what about the (strange) people who really do want to set a limit. Do we just say that they have to live with the message? Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/