[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <533B61AC.7090808@jp.fujitsu.com>
Date: Wed, 02 Apr 2014 10:02:36 +0900
From: Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Davidlohr Bueso <davidlohr@...com>,
Manfred Spraul <manfred@...orfullife.com>, aswin@...com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
"Gotou, Yasunori" <y-goto@...fujitsu.com>,
chenhanxiao <chenhanxiao@...fujitsu.com>,
Gao feng <gaofeng@...fujitsu.com>
Subject: Re: [PATCH] ipc,shm: increase default size for shmmax
(2014/04/02 4:19), Andrew Morton wrote:
> On Tue, 01 Apr 2014 15:29:05 +0900 Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote:
>
>>>
>>> So their system will act as if they had set SHMMAX=enormous. What
>>> problems could that cause?
>>>
>>>
>>> Look. The 32M thing is causing problems. Arbitrarily increasing the
>>> arbitrary 32M to an arbitrary 128M won't fix anything - we still have
>>> the problem. Think bigger, please: how can we make this problem go
>>> away for ever?
>>>
>>
>> Our middleware engineers has been complaining about this sysctl limit.
>> System administrator need to calculate required sysctl value by making sum
>> of all planned middlewares, and middleware provider needs to write "please
>> calculate systcl param by....." in their installation manuals.
>
> Why aren't people just setting the sysctl to a petabyte? What problems
> would that lead to?
>
They(and admin) don't know the fact, setting petabytes won't cause any pain.
In their thinking:
==
If there is a kernel's limit, it should have some (bad) side-effect and
the trade-off which must be handled by admin is represented by the limit.
In this case, they think setting this value large will consume tons of resource.
==
They don't care kernel's implemenation but takes care of what API says.
Of course, always I was asked, I answer set it to peta-bytes. But the fact
*default is small* makes them doubtful.
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists