From nobody Wed Sep 24 11:08:11 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cWvGQ3vWgz68v4W for ; Wed, 24 Sep 2025 11:08:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cWvGQ3KHwz3FfQ for ; Wed, 24 Sep 2025 11:08:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758712094; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=/UfPUu4e+bZEtNFy5oKViE1+X9RGURibiufVSzb8Y4E=; b=VdUwJU6igUOQO3duxST+eo4AxS0xgucCO2mTE+YyW2qjTtwS79g9vh6usIClACncdpHr2L Bi+AW2TWHNu19I7q0xMoZ6zCNIOEGfDU9c0nQIrGsmcOdjtCzYIfXZ0joMyTQifzvbn0hQ 7WYjpxwtLoLJrAPBzw2X5X/y/gJi1NrPhVNAoWWHzxvMhOrlMj9h/ITg8WGa5TSD0+gSgd NxD8zhXP1+ifokDmN+j4qqxo9mKdsysrwfWlMHA961zK6/kMketlrQUYnqPZfexygdSxJl 2xIk9v8+/tEHPJvt15kmVZf5fOhIUrnUcJEmaeNyv685/DBVIOHTlE9OrRLz3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758712094; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=/UfPUu4e+bZEtNFy5oKViE1+X9RGURibiufVSzb8Y4E=; b=c2xmU0McKwvoPFGkQEcKvmpNeu6Wy4xQaEajUySYi5rNEk0P3q/l2ftdvsb+O23eQHQ+sJ GwskVNe5K4NjvNQ70e8ibGWRFobv6u3FFdLWyCj5EWTEJwzfxIAwjhGnFkZei1Ox81MUhg 2zYlgHfv/AxxCzMYuoNZDRayIbnawaJO5/LGUuiLa6H20XXKIKuH+1KeBEzFdF76YDdrro ZJezUyuCERxAqWF8N3QpIvuUHW+Gg5oXn4JJ4RWYQyXt0ZnduAXZvPT3UbzHWS5BKicgQu 8Gb9nPdwkOUk7JM1GdsRoSlUKsHfOe9PD8X+klCZF3s9nKtYQy03ip0395pfnw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758712094; a=rsa-sha256; cv=none; b=AGGP9+snY/nYz76rQ044fA2AtsSbYXUWqIsu2l1/6ckPB/5UmQkxbL/3xvrfDbApPiwgMa ISH6dRtL7oQWVdbLhaFXPDSmPhsOB4EMnk8dyu1g4ieHaQM1831HhP8IamMdogg+n4dyoJ 1dMwKpl4V5y+G88nO6/IEi4AktuGRk4bJybrSl7jaaOQ7gRdD0t35+qffkuoevh+XybGqv Nbz5DlBFnwYmIYoxx6Y+WaFX4CVxHeR34bZUV6VQs30dKAOamtYVqpG00RwahB4EMz4L0Y LdLBzxNhSDWtAPdVEkFKMzEBoulW8P3qEUUHOKbENA+fLGjd7TOCYBfPZn6rvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cWvGQ0x34zNCs for ; Wed, 24 Sep 2025 11:08:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <386e11f1-0e28-4cef-9e6f-7469c7ae40a5@FreeBSD.org> Date: Wed, 24 Sep 2025 14:08:11 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD Current From: Andriy Gapon Subject: limiting jail memory use with rctl/racct Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I wonder if people here use rctl to limit memory utilization for some practical purposes and what your experience is. Recently I had a "bright" idea to limit memory use of Firefox (which, for me, tends to consume all memory and swap impacting everything else on the system). Since Firefox is multi-process now, I decided to use a "null" jail as a resource container. That is, a jail configured with path=/ mount.nodevfs host=inherit ip4=inherit. There is no filesystem or network isolation (so, no security benefits), just grouping of related Firefox processes. The memory limit is set with this rule: jail:firefox-cage:memoryuse:deny=8g I didn't know in advance how the memory limiting would affect Firefox and how Firefox would react to it, so I decided to go ahead and experiment. I want to add that initially I also had a rule to limit swapuse but with it enabled, Firefox wouldn't even start. When I removed the rule I observed that initially rctl reported some absurdly high and unstable swapuse for the jail. Gradually, it went down to some reasonable values. Maybe there is some bug in RACCT code about accounting swap. For example: $ rctl -h -u jail:firefox-cage: | sort coredumpsize=0 cputime=524 datasize=276K maxproc=23 memorylocked=0 memoryuse=8236M msgqqueued=0 msgqsize=0 nmsgq=0 nsem=0 nsemop=0 nshm=0 nthr=559 openfiles=5376 pcpu=93 pseudoterminals=0 readbps=0 readiops=0 shmsize=0 stacksize=8792K swapuse=32G vmemoryuse=73G wallclock=3445 writebps=288 writeiops=2 One minute later: $ rctl -h -u jail:firefox-cage: | sort coredumpsize=0 cputime=588 datasize=312K maxproc=26 memorylocked=0 memoryuse=8249M msgqqueued=0 msgqsize=0 nmsgq=0 nsem=0 nsemop=0 nshm=0 nthr=633 openfiles=5496 pcpu=80 pseudoterminals=0 readbps=0 readiops=0 shmsize=0 stacksize=10M swapuse=19G vmemoryuse=73G wallclock=5140 writebps=32K writeiops=16 So, I had to ditch that rule although I find limiting memoryuse without limiting swapuse to be incomplete. Also, I didn't even consider limiting vmemoryuse because it is very large, it is hard to predict and it seems to have little correlation with the physical memory use. Regarding the experiment, Firefox more or less works, but not without issues. When there are a lot of sites are open in tabs, especially some "web applications" that I have to use and which I know to be memory hogs, Firefox start glitching here and there. Mostly it looks like some broken JavaScript. Another observation is that memoryuse always stays somewhat above the 8 GB limit. Sometimes it's just very slightly above, sometimes it's a couple of hundred megs (or a few percent) above, e.g., memoryuse=8455M. And almost all the time I see a vmdaemon thread being active: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 16 root 119 - 0B 16K CPU4 4 57.1H 68.98% vmdaemon And it's always somewhere in this call chain: procstat -kk 16 PID TID COMM TDNAME KSTACK 16 100177 vmdaemon - vm_swapout_object_deactivate+0x130 vm_swapout_map_deactivate_pages+0x1f3 vm_daemon+0x87d fork_exit+0xc7 fork_trampoline+0xe My impression is that vm_daemon is trying to inactivate some pages belonging to processes in the jail, so that they could get swapped out. But either they get reactivated or the pageout code does not see a need to swap them out and they remain resident. I'd say that this is kind of unexpected consequence. It keeps a CPU core busy and doesn't allow the system to enter power saving states. To conclude, this has a been useful experiment for me. Initially, I had some naive expectations that memory limiting would just magically "limit memory". The experiment forced me to think about what it actually means to limit memory, how it could be done, what consequences it would have and in what cases it could be useful. If anyone has better suggestions and better experience, please let me know. Thanks! -- Andriy Gapon