Re: Bug#642005: general: maximum size of SHM memory blocks to low
reassign 642005 linux-2.6
thanks
On Mon, 19 Sep 2011, Evgeni Golov wrote:
> On 09/19/2011 03:12 AM, Henrique de Moraes Holschuh wrote:
> > On Sun, 18 Sep 2011, Evgeni Golov wrote:
> >> On 09/18/2011 04:46 PM, Henrique de Moraes Holschuh wrote:
> >>> Reassigning to Debian live-config, please reassign elsewhere if
> >>> innapropriate. Note that non-live Debian installs have fairly large SHM
> >>> limits (kernel default, which is half your RAM on Linux), don't reassign
> >>> this to initscripts.
> >>
> >> 32MiB is not half of my 8GB RAM :)
> >
> > Since it was not the kernel who set it to 32MiB, that's hardly surprising, I
> > should say :-p
> >
> > Squeeze's initscripts use the kernel default (50% of your RAM). unstable's
> > initscripts will set it to 20% of your RAM. If it is not live-config which
> > is forcing it to 32MiB, please track down whatever is doing it, and reassign
> > the bug...
>
> Mhh, I can't find *any* reference to shmmax in /etc (neither on Squeeze,
> nor Sid). Are we talking the *same* SHM? Roger pointed out there are two
> kinds of it.
Good call! The kernel limits for the ipc-based shm is entirely
untouched by Debian, and the kernel defaults are to limit it to
32MiB-wide chunks (shmmax) out of a system-wide limit of 8GiB (pagesize
* shmmax).
It is that low because that memory is _NOT_ freed on process exit, and
therefore it can leak way too easily. It has also a long tradition of
being really small by default on all Unixen.
Meh. I doubt we will touch that default, but I don't really care
strongly in one way or the other. Reassigning to the kernel.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: