On Thu, Apr 17, 2014 at 6:41 PM, Manfred Spraul
wrote:
> On 04/17/2014 12:41 PM, Michael Kerrisk wrote:
>>
>> 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, Andre
On 04/17/2014 12:41 PM, Michael Kerrisk wrote:
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
timefram
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 bec
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 s
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 s
On Sun, 2014-04-13 at 20:05 +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 solu
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
(2014/04/02 23:55), One Thousand Gnomes wrote:
Why aren't people just setting the sysctl to a petabyte? What problems
would that lead to?
Historically - hanging on real world desktop systems when someone
accidentally creates a giant SHM segment and maps it.
If you are running with vm overcmmi
> Why aren't people just setting the sysctl to a petabyte? What problems
> would that lead to?
Historically - hanging on real world desktop systems when someone
accidentally creates a giant SHM segment and maps it.
If you are running with vm overcmmit set to actually do checks then it
*shouldn't
On Tue, Apr 01 2014, Kamezawa Hiroyuki wrote:
>> On Tue, Apr 01 2014, Davidlohr Bueso wrote:
>>
>>> On Tue, 2014-04-01 at 19:56 -0400, KOSAKI Motohiro wrote:
>>> Ah-hah, that's interesting info.
>>>
>>> Let's make the default 64GB?
>>
>> 64GB is infinity at that time, but i
(2014/04/02 10:08), Greg Thelen wrote:
>
> On Tue, Apr 01 2014, Davidlohr Bueso wrote:
>
>> On Tue, 2014-04-01 at 19:56 -0400, KOSAKI Motohiro wrote:
>> Ah-hah, that's interesting info.
>>
>> Let's make the default 64GB?
>
> 64GB is infinity at that time, but it no longer nea
On Tue, Apr 01 2014, Davidlohr Bueso wrote:
> On Tue, 2014-04-01 at 19:56 -0400, KOSAKI Motohiro wrote:
>> >> > Ah-hah, that's interesting info.
>> >> >
>> >> > Let's make the default 64GB?
>> >>
>> >> 64GB is infinity at that time, but it no longer near infinity today. I
>> >> like
>> >> very
(2014/04/02 4:19), Andrew Morton wrote:
On Tue, 01 Apr 2014 15:29:05 +0900 Kamezawa Hiroyuki
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 arbitr
On Tue, 2014-04-01 at 19:56 -0400, KOSAKI Motohiro wrote:
> >> > Ah-hah, that's interesting info.
> >> >
> >> > Let's make the default 64GB?
> >>
> >> 64GB is infinity at that time, but it no longer near infinity today. I like
> >> very large or total memory proportional number.
> >
> > So I still
(2014/04/02 5:15), KOSAKI Motohiro wrote:
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
>> > Ah-hah, that's interesting info.
>> >
>> > Let's make the default 64GB?
>>
>> 64GB is infinity at that time, but it no longer near infinity today. I like
>> very large or total memory proportional number.
>
> So I still like 0 for unlimited. Nice, clean and much easier to look at
> than ULONG_
On Tue, 2014-04-01 at 18:49 -0400, KOSAKI Motohiro wrote:
> On Tue, Apr 1, 2014 at 5:48 PM, Andrew Morton
> wrote:
> > On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro
> > wrote:
> >
> >> >> > Hmmm so 0 won't really work because it could be weirdly used to
> >> >> > disable
> >> >> > shm alto
On Tue, Apr 1, 2014 at 5:48 PM, Andrew Morton wrote:
> On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro
> wrote:
>
>> >> > Hmmm so 0 won't really work because it could be weirdly used to disable
>> >> > shm altogether... we cannot go to some negative value either since we're
>> >> > dealing wit
On Tue, 01 Apr 2014 15:02:31 -0700 Davidlohr Bueso wrote:
> On Tue, 2014-04-01 at 14:48 -0700, Andrew Morton wrote:
> > On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro
> > wrote:
> >
> > > >> > Hmmm so 0 won't really work because it could be weirdly used to
> > > >> > disable
> > > >> > shm
On Tue, 2014-04-01 at 14:48 -0700, Andrew Morton wrote:
> On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro
> wrote:
>
> > >> > Hmmm so 0 won't really work because it could be weirdly used to disable
> > >> > shm altogether... we cannot go to some negative value either since
> > >> > we're
> >
On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro
wrote:
> >> > Hmmm so 0 won't really work because it could be weirdly used to disable
> >> > shm altogether... we cannot go to some negative value either since we're
> >> > dealing with unsigned, and cutting the range in half could also hurt
> >>
On Tue, 2014-04-01 at 17:12 -0400, KOSAKI Motohiro wrote:
> On Tue, Apr 1, 2014 at 5:01 PM, Davidlohr Bueso wrote:
> > On Tue, 2014-04-01 at 15:51 -0400, KOSAKI Motohiro wrote:
> >> >> So, I personally like 0 byte per default.
> >> >
> >> > If by this you mean 0 bytes == unlimited, then I agree. I
>> > Hmmm so 0 won't really work because it could be weirdly used to disable
>> > shm altogether... we cannot go to some negative value either since we're
>> > dealing with unsigned, and cutting the range in half could also hurt
>> > users that set the limit above that. So I was thinking of simply
On Tue, 1 Apr 2014 17:12:50 -0400 KOSAKI Motohiro
wrote:
> On Tue, Apr 1, 2014 at 5:01 PM, Davidlohr Bueso wrote:
> > On Tue, 2014-04-01 at 15:51 -0400, KOSAKI Motohiro wrote:
> >> >> So, I personally like 0 byte per default.
> >> >
> >> > If by this you mean 0 bytes == unlimited, then I agree.
On Tue, Apr 1, 2014 at 5:01 PM, Davidlohr Bueso wrote:
> On Tue, 2014-04-01 at 15:51 -0400, KOSAKI Motohiro wrote:
>> >> So, I personally like 0 byte per default.
>> >
>> > If by this you mean 0 bytes == unlimited, then I agree. It's less harsh
>> > then removing it entirely. So instead of removin
On Tue, 2014-04-01 at 15:51 -0400, KOSAKI Motohiro wrote:
> >> So, I personally like 0 byte per default.
> >
> > If by this you mean 0 bytes == unlimited, then I agree. It's less harsh
> > then removing it entirely. So instead of removing the limit we can just
> > set it by default to 0, and in new
On Tue, 2014-04-01 at 16:15 -0400, KOSAKI Motohiro wrote:
> >> 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
> >>
>> 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.
>
>
On Tue, Apr 1, 2014 at 2:31 PM, Davidlohr Bueso wrote:
> On Tue, 2014-04-01 at 14:10 -0400, KOSAKI Motohiro wrote:
>> On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso wrote:
>> > On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
>> >> On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso
>> >
On Tue, 01 Apr 2014 10:01:39 -0700 Davidlohr Bueso wrote:
> > > EINVAL A new segment was to be created and size < SHMMIN or size >
> > > SHMMAX, or no new segment was to be created, a segment with given key
> > > existed, but size is greater than the size of that segment.
> >
> > So their system
On Tue, 01 Apr 2014 15:29:05 +0900 Kamezawa Hiroyuki
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
On Tue, 2014-04-01 at 14:10 -0400, KOSAKI Motohiro wrote:
> On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso wrote:
> > On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
> >> On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso
> >> wrote:
> >>
> >> > On Mon, 2014-03-31 at 16:13 -0700, Andrew
On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso wrote:
> On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
>> On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso wrote:
>>
>> > On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
>> > > On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso
On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
> On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso wrote:
>
> > On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
> > > On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso
> > > wrote:
> > >
> > > > >
> > > > > - Shouldn't there b
(2014/04/01 9:05), Andrew Morton wrote:
On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso wrote:
On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso wrote:
- Shouldn't there be a way to alter this namespace's shm_ctlmax?
Unfortunat
On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso wrote:
> On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
> > On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso wrote:
> >
> > > >
> > > > - Shouldn't there be a way to alter this namespace's shm_ctlmax?
> > >
> > > Unfortunately this
On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
> On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso wrote:
>
> > >
> > > - Shouldn't there be a way to alter this namespace's shm_ctlmax?
> >
> > Unfortunately this would also add the complexity I previously mentioned.
>
> But if the cur
On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso wrote:
> >
> > - Shouldn't there be a way to alter this namespace's shm_ctlmax?
>
> Unfortunately this would also add the complexity I previously mentioned.
But if the current namespace's shm_ctlmax is too small, you're screwed.
Have to shut d
On Mon, 2014-03-31 at 14:32 -0700, Andrew Morton wrote:
> On Sun, 30 Mar 2014 20:06:39 -0700 Davidlohr Bueso wrote:
>
> > From: Davidlohr Bueso
> >
> > The default size is, and always has been, 32Mb. Today, in the
> > XXI century, it seems that this value is rather small, making
> > users have
On Sun, 30 Mar 2014 20:06:39 -0700 Davidlohr Bueso wrote:
> From: Davidlohr Bueso
>
> The default size is, and always has been, 32Mb. Today, in the
> XXI century, it seems that this value is rather small, making
> users have to increase it via sysctl, which can cause unnecessary
> work and user
From: Davidlohr Bueso
The default size is, and always has been, 32Mb. Today, in the
XXI century, it seems that this value is rather small, making
users have to increase it via sysctl, which can cause unnecessary
work and userspace application workarounds[1]. I have arbitrarily
chosen a 4x increas
41 matches
Mail list logo
