02:12:48 Thanks for your insights about the "5.11" release number. 06:14:11 My OI illumos VM is now on a PCIe v3 M.2 card, the VM feels very snappy now. 08:38:15 Hi, is https://pkgsrc.smartos.org/ still alive? There are no commits since February on github 08:44:15 unixery: very much so, I don't use the default branch so it doesn't get updated very often, everything happens over on the main pkgsrc repository or my feature/release branches 08:51:27 what do you mean by "the main pkgsrc repository"? The NetBSD repo? 08:51:39 yes 09:01:10 but aren't the packages for illumos/macos build from the pkgsrc.smartos.org repo? Or how do package updates happen? 09:02:35 yes but not from the default branch, they're built from the 'release/*' branches (e.g. release/trunk for illumos, release/macos for macOS) 09:03:50 there's a doc I need to update for post-Joyent changes but it's roughly https://github.com/TritonDataCenter/pkgsrc/wiki/about:workflow 09:07:02 thanks! I've missed the release branches while scrolling. The branch list is long ;-) 09:07:19 we have a lot of history! ;) 09:15:50 BTW: could this be fixed https://github.com/TritonDataCenter/pkgsrc/issues/384 ? Missing wg-quick is the reason why I still have MacPorts on my Mac 09:19:15 sure, I'll take a look now 09:52:48 done, but as per comment it'll probably be a few days until it shows up 10:48:07 great, thanks! 18:18:09 i don't suppose there's a way to force /bin/cat to not use mmap? 18:25:13 ksh cat looks like it doesn't, but uses a 64k buf 18:32:55 jbk: LD_PRELOAD that neuters mmap? Use dd instead of cat? 18:33:49 jbk: For a particular reason, or? 18:37:27 for reasons that i really don't have time to investigate, each 8mb mmap64 is taken 1-2s to do.. which means combining ~40 2gb files into one is taking hours 18:38:14 the writes are basically instantaneous 18:43:12 What is the source FS ?! 18:43:16 It's SMB isn't it haha 18:44:23 fastest workaround is probably to substitute dd with appropriate options instead of cat 19:00:00 I'm using a little ed script to edit a *.json file and to my surprise, ed is adding carriage returns to all the lines when I write out the result. Anyone run into that? Any idea why that happens? How to prevent it? 19:07:00 Huh. Seems to have to do with a missing newline at the end of the file. If I fix that first, then "ed" works as expected. 19:48:56 I have ancient memories that that's one of the unix demanding a newline things (ed appending a single one, at the end). Interspersing them would be new to me 20:32:04 matters of taste aside, does anyone known when anonymous unions became standard? 22:25:34 Anonymous unions were added in C11 22:26:13 Anyone have advice on tuning a (large) system to avoid seg_kp allocation failures? I've not run into this before. 22:26:23 thanks gwr 22:27:36 you're running out of pageable addresses!? 22:27:52 I don't have that experience, no 22:28:00 we probably need a bit more to really support them well.. i had done some stuff with mdb, but after a lot more investigation, i think it might make more sense to modify libctf when looking up struct/union members to deal with anonymous ones... i think mdb and dtrace would then DTRT 22:30:50 gwr: how much swap do you have? 22:30:56 v. how much physical memory 22:31:07 v. how much you're trying to allocate? 22:31:46 I don't immediately see ways this would fail unless we have actually run out of resources to hand out 22:32:05 in which case I think the only solution is more of those resources (probably VM) 22:34:40 It appears we've run out. physmem is 0xbfaca94 22:40:38 gwr: How many LWPs do you have? 22:40:55 I feel like that's usually what drove us to run out in the past 22:41:05 about 5100 22:41:12 That doesn't seem like that many! 22:42:17 I assume your segkpsize is at the default of 524288 pages (2GB) 22:43:49 segkpsize = 0x80000 22:44:16 so yes 22:45:05 A pthread_create failed in user-level.... 22:45:21 right 22:45:31 well it would, as you're out of something an LWP needs to exist 22:55:40 gwr: What do you get from "::vmem segkp ! grep segkp" 22:56:47 For nthread = 2799 I only have ~82MB in use there 22:56:59 also 0 failed allocations etc 22:58:09 that comes out to about 29KB/thread, which I think makes sense, as lwp_default_stksize is 20480