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,
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
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
On Thu, Apr 17, 2014 at 12:46 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul manf...@colorfullife.com
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
On 04/17/2014 12:41 PM, Michael Kerrisk wrote:
On Thu, Apr 17, 2014 at 12:46 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul manf...@colorfullife.com
wrote:
Hi Andrew,
On 04/02/2014 12:08 AM, Andrew Morton wrote:
Well, I'm assuming
On Thu, Apr 17, 2014 at 6:41 PM, Manfred Spraul
manf...@colorfullife.com wrote:
On 04/17/2014 12:41 PM, Michael Kerrisk wrote:
On Thu, Apr 17, 2014 at 12:46 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul
manf...@colorfullife.com wrote:
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
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
On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul manf...@colorfullife.com
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
On Wed, 2014-04-16 at 15:46 -0700, Andrew Morton wrote:
On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul manf...@colorfullife.com
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
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
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 -
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 -
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 solution:
(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
> 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
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*
(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
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
(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
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
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."
>> > 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
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
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
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
> > > >> >
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.
>> > 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
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
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
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
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
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,
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
(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?
(2014/04/01 9:05), Andrew Morton wrote:
On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso davidl...@hp.com wrote:
- Shouldn't there be a way to alter this
On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso davidl...@hp.com
wrote:
-
On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 15:59:33
On Tue, 2014-04-01 at 14:10 -0400, KOSAKI Motohiro wrote:
On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso davidl...@hp.com
wrote:
On Mon, 2014-03-31 at
On Tue, 01 Apr 2014 15:29:05 +0900 Kamezawa Hiroyuki
kamezawa.hir...@jp.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
On Tue, 01 Apr 2014 10:01:39 -0700 Davidlohr Bueso davidl...@hp.com 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
On Tue, Apr 1, 2014 at 2:31 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Tue, 2014-04-01 at 14:10 -0400, KOSAKI Motohiro wrote:
On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 16:25:32 -0700
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
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
calculate
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 newseg() if
On Tue, Apr 1, 2014 at 5:01 PM, Davidlohr Bueso davidl...@hp.com 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
On Tue, 1 Apr 2014 17:12:50 -0400 KOSAKI Motohiro kosaki.motoh...@gmail.com
wrote:
On Tue, Apr 1, 2014 at 5:01 PM, Davidlohr Bueso davidl...@hp.com 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
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 setting
On Tue, 2014-04-01 at 17:12 -0400, KOSAKI Motohiro wrote:
On Tue, Apr 1, 2014 at 5:01 PM, Davidlohr Bueso davidl...@hp.com 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, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro kosaki.motoh...@gmail.com
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
On Tue, 2014-04-01 at 14:48 -0700, Andrew Morton wrote:
On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro kosaki.motoh...@gmail.com
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
On Tue, 01 Apr 2014 15:02:31 -0700 Davidlohr Bueso davidl...@hp.com wrote:
On Tue, 2014-04-01 at 14:48 -0700, Andrew Morton wrote:
On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
Hmmm so 0 won't really work because it could be weirdly used to
On Tue, Apr 1, 2014 at 5:48 PM, Andrew Morton a...@linux-foundation.org wrote:
On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro kosaki.motoh...@gmail.com
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
On Tue, 2014-04-01 at 18:49 -0400, KOSAKI Motohiro wrote:
On Tue, Apr 1, 2014 at 5:48 PM, Andrew Morton a...@linux-foundation.org
wrote:
On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
Hmmm so 0 won't really work because it could be weirdly used to
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_MAX. And since we
(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
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 like 0 for unlimited.
(2014/04/02 4:19), Andrew Morton wrote:
On Tue, 01 Apr 2014 15:29:05 +0900 Kamezawa Hiroyuki
kamezawa.hir...@jp.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
On Tue, Apr 01 2014, Davidlohr Bueso davidl...@hp.com 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 large or total
(2014/04/02 10:08), Greg Thelen wrote:
On Tue, Apr 01 2014, Davidlohr Bueso davidl...@hp.com 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
On Tue, Apr 01 2014, Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com wrote:
On Tue, Apr 01 2014, Davidlohr Bueso davidl...@hp.com 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
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
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
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
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
On Sun, 30 Mar 2014 20:06:39 -0700 Davidlohr Bueso davidl...@hp.com wrote:
From: Davidlohr Bueso davidl...@hp.com
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
On Mon, 2014-03-31 at 14:32 -0700, Andrew Morton wrote:
On Sun, 30 Mar 2014 20:06:39 -0700 Davidlohr Bueso davidl...@hp.com wrote:
From: Davidlohr Bueso davidl...@hp.com
The default size is, and always has been, 32Mb. Today, in the
XXI century, it seems that this value is rather small,
On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso davidl...@hp.com 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.
On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso davidl...@hp.com 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
On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso davidl...@hp.com wrote:
- Shouldn't there be a way to alter this namespace's shm_ctlmax?
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
From: Davidlohr Bueso davidl...@hp.com
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
82 matches
Mail list logo
