!RROtHmAaQIkiJzJZZE:nixos.org

NixOS Infrastructure

381 Members
Next Infra call: 2024-07-11, 18:00 CEST (UTC+2) | Infra operational issues backlog: https://github.com/orgs/NixOS/projects/52 | See #infra-alerts:nixos.org for real time alerts from Prometheus.116 Servers

Load older messages


SenderMessageTime
13 Feb 2025
@hexa:lossy.networkhexa not sure if John Ericson knows anything else by now 01:14:34
@joerg:thalheim.ioMic92Okay will check for today 01:15:01
@joerg:thalheim.ioMic92I have machines with a lot of ram and core count but haven't seen that so far01:16:19
@joerg:thalheim.ioMic92But maybe libc needs to flush if it gets to the pipe buffer limit regardless of a missing newline01:17:32
@emilazy:matrix.orgemilyI wouldn't rely on multiple processes writing into the same stream pipe.01:18:04
@emilazy:matrix.orgemilythat's just the wrong primitive and will never work fully reliably01:18:17
@joerg:thalheim.ioMic92I can just add a lock around it01:18:27
@joerg:thalheim.ioMic92We are not really limited by the speed to write to stdout01:18:48
@joerg:thalheim.ioMic92On nixpkgs it's slow enough that I can almost read it01:19:06
@Ericson2314:matrix.orgJohn Ericson Mic92: yeah everything is in the issue 01:21:22
@Ericson2314:matrix.orgJohn EricsonI know nothing that anyone else doesn't01:21:28
@Ericson2314:matrix.orgJohn Ericson I do agree with emily that multiple pipes/sockets feels better than locking 01:21:52
@Ericson2314:matrix.orgJohn Ericsonor are you sending everything back to the main process anyways, so it is in a good position to mux them?01:22:11
@joerg:thalheim.ioMic92I would prefer it though since it makes it very easy to use. At least unless we identify this an actual performance bottleneck 01:24:16
@joerg:thalheim.ioMic92* I would prefer a single output though since it makes it very easy to use. At least unless we identify this an actual performance bottleneck 01:24:32
@joerg:thalheim.ioMic92I am thinking of all the other ci integrations that people build with it01:25:21
@joerg:thalheim.ioMic92
In reply to @Ericson2314:matrix.org
or are you sending everything back to the main process anyways, so it is in a good position to mux them?
I don't remember the details because this code already existed when I copied it out of hydra
01:48:03
@Ericson2314:matrix.orgJohn Ericson Mic92: My guess is the non-streaming version made the central process buffer everything and accumulate one big message 01:48:44
@Ericson2314:matrix.orgJohn Ericsonbut when we switched to streaming, each worker started writing down the pipe itself01:48:54
@Ericson2314:matrix.orgJohn EricsonSo I am gonna guess roughtly that means "easy mode" should be the old way, while "fast mode" should be the socket way01:49:32
@joerg:thalheim.ioMic92I'll run perf on the version with the lock01:50:51
@joerg:thalheim.ioMic92Libc already uses internal locks internally for buffered files01:55:39
@Ericson2314:matrix.orgJohn EricsonOK, well as long as it works :)01:57:01
@joerg:thalheim.ioMic92Nan is working on the nix-eval-jobs fix.04:10:06
@joerg:thalheim.ioMic92 hexa (signing key rotation when): John Ericson https://github.com/nix-community/nix-eval-jobs/pull/351 05:48:03
@Ericson2314:matrix.orgJohn Ericson Mic92: Awesome! 06:27:31
@Ericson2314:matrix.orgJohn EricsonLet's give it a go! :)06:27:38
@irrelevancy:matrix.orgirrelevancyisthygoal One Confused Being joined the room.08:12:31
@hexa:lossy.networkhexaupdating nix-eval-jobs10:05:27
@mrdgh2821:matrix.org@mrdgh2821:matrix.org joined the room.10:40:44

Show newer messages


Back to Room ListRoom Version: 6