rctl mess - is it a bug or mis-config on my end?

Something seems to be not quite right with rctl(8) .

According to the klarasystems blog, I can limit the amount of RAM a jail(8) uses:
1679187671696.png

Based on that, I thought I could limit the amount of RAM a jail with Firefox uses. I followed the wiki: https://wiki.freebsd.org/JailingGUIApplications . I had to modify the procedure to get Firefox working.

My idea was, on a laptop with 8 GB of RAM, I could limit a jail with Firefox to using just 4 GB of RAM. But this idea is just not working:
Code:
# rctl -h
jail:firefox:memoryuse:deny=4096M
# xhost +
access control disabled, clients can connect from any host
# jail -c firefox
Firefox starts fine. BUT from get-go, it grabs more than 1.6 GB of RAM, before I navigate anywhere.
Code:
# rctl -uh jail:firefox | grep memory
memoryuse=1654M
memorylocked=0
vmemoryuse=16G
Going to Discord and logging in: That grabs over a GB of RAM, and vmemory use is through the roof.
Code:
# rctl -uh jail:firefox | grep memory
memoryuse=2745M
memorylocked=0
vmemoryuse=35G
Opening up tenor.com in a separate tab: (Yeah, not a very good representation, because I did visit it earlier, also opened it up in a separate tab, and had KDE freeze up on me. An attempt to repeat the procedure for taking down notes on how that step affects me - that goes way smoother than last time!) Grab 814 MB more of RAM.
Code:
# rctl -uh jail:firefox | grep memory
memoryuse=3559M
memorylocked=0
vmemoryuse=30G
Opening espn.com in a new tab: That makes the whole system freeze up, I'm unable to move the mouse, or SSH in. Only a hard reboot gets me unstuck. And one more thing: Before I even had the idea to take these notes, I've seen memoryuse=4286M! I thought I limited it to 4096 MB???

Hopefully a dev sees this, and maybe can give some suggestions: If there's a bug to be filed, I'd appreciate a link... There's always a possibility that I didn't understand something about the design of jail(8) or rctl(8) and used some incompatible options - if there's a good way to explain that, I'd love to learn that.

Or is firefox just pushing the technical limits of what a jail can do? I've seen info that a dev gave up trying to port ff's memory management to FreeBSD. I wish I discovered this earlier when I was making a wishlist for the FreeBSD Foundation... oh well.

Edit: Had to delete a bit of accidentally duplicated text from this post.
 
Yeah that's about the case with firefox. In the two-digit versions there was a config option inside firefox, where one could choose how many parallel workers to engage. One could set that to 2 (because a single user cannot work on multiple tabs at the same time), and that would usually help.
Now that option has been done away with, and I thought there should be a knob somewhere to adjust ressource consumption, and started searching. There are some options in about:config, but they do not work, and, looking further, firefox seems to obtain the system ressources information (memory and cores) from devel/nspr - but manupulating that there does also not work - and it is not really intellegible how things might interact (if at all).

rctl, otoh, can only deny requests - so what do you expect firefox to do when it gets ENOMEM? I think this only works when the application plays along. I once tried to limit memory via rctl, and wasn't successful: in one case the application just failed, and in the other case lots of load was pushed onto vmdaemon&friends to move the memory around.

BTW, you do not necessarily need a jail to play with rctl. It can also work with loginclasses, and a loginclass is just an arbitrary name. You can set any process to any loginclass by executing setloginclass(), e.g. in some prefix program. Only downside: that call has to be done as root.
 
This seems to be actively discussed on FreeBSD's bugzilla:
PR 263436 seems to indicate this started with FF 98, and still unresolved as of 107... I'm on 110.
 
Back
Top