| 27 Oct 2024 |
 Artturin | * lovesegfault: https://github.com/NixOS/nix/pull/6645#issuecomment-1230341511 are you still patching it yourself? | 23:37:17 |
 emily | (set it if it's lower, I mean, so no change for Linux.) | 23:38:35 |
| emily | doing something fancier in Nix may also be nice but one line in stdenv to avoiding hacks in Nixpkgs derivations now seems like a good trade-off. | 23:39:06 |
| Artturin | yep | 23:39:20 |
| emily | /*
* This structure is used for the management of descriptors. It may be
* shared by multiple processes.
*
* A process is initially started out with NDFILE descriptors [XXXstored within
* this structureXXX], selected to be enough for typical applications based on
* the historical limit of 20 open files (and the usage of descriptors by
* shells). If these descriptors are exhausted, a larger descriptor table
* may be allocated, up to a process' resource limit; [XXXthe internal arrays
* are then unusedXXX]. The initial expansion is set to NDEXTENT; each time
* it runs out, it is doubled until the resource limit is reached. NDEXTENT
* should be selected to be the biggest multiple of OFILESIZE (see below)
* that will fit in a power-of-two sized piece of memory.
*/
#define NDFILE 25 /* 125 bytes */
#define NDEXTENT 50 /* 250 bytes in 256-byte alloc. */
| 23:43:32 |
| emily | thankfully XNU is open source! | 23:43:44 |
| emily | so, it won't cause any memory increase out of the box to set it to 122880. | 23:43:53 |
| emily | therefore it seems fine, the only risk is processes using up all of them which would be a whopping 600 KiB. | 23:44:43 |
| emily | so I'll just do that. | 23:44:48 |
| emily | reno: you have a macOS 11 VM, right? what's kern.maxfilesperproc there? | 23:47:44 |
| emily | it turns out that it's 10240 on 10.12 so we probably can't go above that for now >:( | 23:47:55 |
| Artturin | What happens when you set it above the max | 23:48:23 |
| emily | it fails. | 23:48:30 |
 @paparodeo:matrix.org | In reply to @emilazy:matrix.org
it turns out that it's 10240 on 10.12 so we probably can't go above that for now >:( kern.maxfilesperproc: 98304 | 23:48:33 |
| emily | and I don't want to implement conditional logic. | 23:48:36 |
| emily | In reply to @paparodeo:matrix.org
kern.maxfilesperproc: 98304 wow they really just keep bumping it up | 23:48:43 |
| emily | ok I'll put it at 10240 for now. | 23:48:49 |
| emily | ridiculous number. | 23:48:53 |
| Artturin | ulimit || ulimit || ulimit | 23:49:09 |
| emily | they could at last have made it 16384 | 23:49:14 |
| emily | In reply to @artturin:matrix.org
ulimit || ulimit || ulimit yeah. but otoh nothing in the tree sets it above 8196. | 23:49:23 |
| emily | so it doesn't seem worth it. I can bump it as a treat to myself every time I bump the minimum macOS version. | 23:49:35 |
| Artturin | https://github.com/LnL7/nix-darwin/blob/5c0c6aaa797d6ccbb6cdab14de0248135735709d/modules/services/nix-daemon.nix#L51 | 23:52:35 |
| Artturin | nix-darwin has 1048576 | 23:52:40 |
| Artturin | Wonder if it's applying for them | 23:53:05 |
| emily | https://github.com/LnL7/nix-darwin/commit/ec06ea883757c6075c61d1426f40719742d51f59 | 23:53:24 |
| emily | was just copied from Nix | 23:53:31 |
| emily | you definitely can't go above kern.maxfilesperproc so my expectation is that it's either doing nothing or getting silently capped | 23:54:01 |
| emily | and apparently not passing down to builds anyway(?) | 23:54:10 |
| 28 Oct 2024 |
| Artturin | Commented https://github.com/LnL7/nix-darwin/pull/940/files#r1818220494 | 00:02:36 |
