Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756971AbaDPXTJ (ORCPT ); Wed, 16 Apr 2014 19:19:09 -0400 Received: from g4t3427.houston.hp.com ([15.201.208.55]:11865 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755556AbaDPXTG (ORCPT ); Wed, 16 Apr 2014 19:19:06 -0400 Message-ID: <1397690343.2556.15.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH] ipc,shm: increase default size for shmmax From: Davidlohr Bueso To: Andrew Morton Cc: Manfred Spraul , KOSAKI Motohiro , aswin@hp.com, LKML , "linux-mm@kvack.org" , Michael Kerrisk Date: Wed, 16 Apr 2014 16:19:03 -0700 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2014-04-16 at 15:46 -0700, 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. > > In an ideal world, system administrators would review this change, > 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? That's a good idea, and along with the manpage update (+ probably some blog/lwn post) users should be well informed. We want them to update their scripts. Cc'ing Michael Kerrisk btw, who might give us a fresh userspace perspective. > I think the changelogs for both patches could afford to spend much more > time talking about *why* we're making this change. What problem is > the current code causing? This is a somewhat risky change and we > should demonstrate good reasons for making it. If people end up taking > damage because of this change, they are going to be looking at that > changelog trying to work out why we did this to them, so let's explain > it carefully. Fair enough, although that's really why I added the link to Robert Haas' blog post. In my past life I did some technical support for Oracle, so I *know* the pain such limits can cause. How does the following sound? "Unix has historically required setting these limits for shared memory, and Linux inherited such behavior. The consequence of this is added complexity for users and administrators. One very common example are Database setup/installation documents and scripts, where users must manually calculate the values for these limits. This also requires (some) knowledge of how the underlying memory management works, thus causing, in many occasions, the limits to just be flat out wrong. Disabling these limits sooner could have saved companies a lot of time, headaches and money for support. But it's never too late, simplify users life now." -- 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/