[kde-freebsd] [CFT] kde-games fix for (invalid shared segment parameter)

[Alberto Villa]

On Fri, Mar 9, 2012 at 1:57 PM, Alberto Villa <avilla at freebsd.org> wrote:
> Then: we *must* fix raster graphics system. LooX, did you get any
> interesting result with your sysctl tweaking (I remember you said on
> IRC you have the same problem)? Can you paste the output of `ipcs -m`
> and `sysctl kern.ipc` after being logged in for a while?

OK, I played with kern.ipc.shm* with a bit more wisdom and I think I
see the solution.

First thing first: I don't get why Marble and KDE-Games were not
working with Qt 4.7. Can anyone with Qt 4.7 please...

# sysctl kern.ipc.shm_allow_removed=0
$ marble &
$ kajongg &
$ ipcs -am > $logfile
$ killall marble
$ killall kajongg
$ ipcs -am >> $logfile
$ ipcs -M >> $logfile

... and attach $logfile? Should you want to repeat it with
kern.ipc.shm_allow_removed=1, it would be nice.

Now, the problem is not with shmmax or shmall (which set a size limit
to shared memory) - or, at least, it's not for me, as if you are short
of memory those tunables might be a bit low (I have 4 GB of RAM and
they're set to 500 MB). Anyway, setting those to low values should not
be a problem, apart for reduced performance. I'll test it.

The problem is with the limit to shared memory segments: shmmni, which
is the maximum allowed number of memory identifiers (i.e., segments on
the system), and shmseg, which is the same thing, but per-process.
These were set to about 1xx (I don't remember), but Plasma alone needs
~130 after 15 minutes of system usage with two KDE activities. Now add
all other programs: with Amarok, Konsole and Rekonq I'm using 173 of
them, and each instance of Dragon Player playing a movie requires 60
more (but Marble, for example, only needs 4, that's why I don't
understand why it was failing on Qt 4.7). The system knows the memory
limit is far away (shmall), tries to allocate a new identifier, and
fails. I wonder why it doesn't behave more smartly.
To conclude, I've set 256 for both those tunables, but it's not enough
yet (with the two Dragon Players i got over 250, and one of them
stopped working): shmmni probably can't be less than 512, while smhseg
at 256 looks quite safe.

For those of you thinking "Do I really want to have so high limits?",
my current shared memory usage, with 173 segments, is of 27 MB, so
it's not insane at all. And don't remember you're still limited by
shmall and shmmax, which won't let shared memory go over shmall * 4 kB
(while shmmax is the limit to segment size).

All of this is with kern.ipc.shm_allow_removed=0, and raster graphics
system is running smoothly.
So, just add kern.ipc.shmmni=512 and kern.ipc.shmseg=256 to
/boot/loader.conf, and experiment with those if you have problems
(remember to report your results).

Now, I've written my experience to help anyone testing Qt 4.8, but we
need to get in touch with some src/ people to ask for confirmation of
my analysis, and for resonable values.
This is surely something PC-BSD is interested in, and probably these
tunables should be added to "sane desktop defaults" along with
kern.sched.preempt_thresh=224. I'll forward the mail to desktop at .
-- 
Alberto Villa, FreeBSD committer <avilla at FreeBSD.org>
http://people.FreeBSD.org/~avilla