On Fri, Mar 9, 2012 at 1:57 PM, Alberto Villa <avi...@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@. -- Alberto Villa, FreeBSD committer <avi...@freebsd.org> http://people.FreeBSD.org/~avilla _______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
