03:23:43 <jclulow> I feel like we could have not dboot today if loader left us in the right mode and just did ELF
03:24:50 <jclulow> I thought UEFI allowed long mode applications already 
09:27:37 <tsoome> jclulow that is true.
15:16:29 <gitomat> [illumos-gate] 15637 cstyle common/devid/devid_scsi.c -- Hans Rosenfeld <rosenfeld⊙gho>
15:17:12 <gitomat> [illumos-gate] 15636 fix scsi inquiry page 83 warnings -- Hans Rosenfeld <rosenfeld⊙gho>
15:18:02 <gitomat> [illumos-gate] 15638 panic in scsi_hba_ioctl() -- Hans Rosenfeld <rosenfeld⊙gho>
16:44:03 <gitomat> [illumos-gate] 15591 idmap becomes non-functional after system memory shortage -- Gordon Ross <gwr⊙rc>
16:48:33 <gitomat> [illumos-gate] 15592 SMB should check taskq_dispatch returns -- Gordon Ross <gwr⊙rc>
16:51:03 <gitomat> [illumos-gate] 15684 ficl: remove duplicate target 'all' -- Toomas Soome <tsoome⊙mc>
16:57:22 <gitomat> [illumos-gate] 14380 pam_modules: build errors with gcc 11 -- Toomas Soome <tsoome⊙mc>
16:58:28 <tsoome> with 14380, my gcc 11 branch is now empty.
17:02:39 <gitomat> [illumos-gate] 15673 acpica: storing the address of local variable -- Toomas Soome <tsoome⊙mc>
17:08:22 <gitomat> [illumos-gate] 15596 SMB should export a header for kstats -- Gordon Ross <gwr⊙nc>
17:11:04 <gitomat> [illumos-gate] 15598 Allow dtrace SET_ERROR probes in libfksmbsrv -- Gordon Ross <gordon.ross⊙tc>
17:12:36 <andyf> tsoome - congratulations! You reminded me that I do have the things ready for creating an illumos gcc12..
17:16:04 <andyf> er, 13..
17:40:09 <richlowe> 13 is the one everyone is excited about
17:40:39 <andyf> Oh yes, and I think it is what most parties are agreed on as the next shadow target. I just forgot briefly
17:45:13 <danmcd> Thank you richlowe -- I was curious what I replace gcc7 with for the shadow.
17:47:28 <sommerfeld> in looking at 15667, one of the things that stands out is inefficiency of access to the thread-local locale pointer.  has anyone looked at faster thread-local storage?  (it looks like gcc can do it, using one of the segment registers on x86 as a thread-local base pointer)
17:49:33 <richlowe> when you say "faster thread-local storage" do you mean actual TLS? and __thread?
17:49:41 <rmustacc> No. uselocale() uses tsdalloc.
17:49:50 <rmustacc> So we need to see what tsd index it actually gets.
17:50:08 <sommerfeld> Yes, true thread-local storage.  
17:50:18 <richlowe> it works we use it in a small handful of places
17:50:53 <rmustacc> So what key index does it get?
17:51:07 <richlowe> I don't understand the question
17:51:21 <richlowe> why does it need a key-index if it's using real TLS?
17:51:55 <rmustacc> It's not.
17:52:03 <richlowe> no, sommerfeld is asking if it _could_
17:52:43 <rmustacc> Sorry, I misunderstood. I took that to be could tsdalloc() be faster. Not a different mechanism.
17:53:09 <rmustacc> Is uselocale() showing up in a flamegraph?
17:53:40 <richlowe> the only general comment I have is that TLS is complicated in ld, and it was convenient for ARM to not have to worry about it at first.
17:54:05 <richlowe> so it would be a _nice_ thing if the access to TLS was abstracted so anyone in a similar hole could dodge it.
17:54:12 <richlowe> rather than the naked global data __thread we find in libses and co
17:54:23 <richlowe> (but global data sucks anyway, so...)
17:54:46 <sommerfeld> haven't done a flamegraph but the preliminary profiling I did showed it getting called 10+ times per input character for the sample regexp.
17:55:19 <sommerfeld> and tweaks to avoid those calls led to a significant speedup.
18:07:55 <rmustacc> sommerfeld: That's... a lot.
18:08:01 <sommerfeld> yes.
18:08:28 <rmustacc> We should probably reduce the number of calls there. It definitely hasn't been looked at in anger in this way sometimes.
18:08:39 <rmustacc> I guess I wonder if it's going to be about reducing the cost or if we can reduce the calls.
18:09:25 <sommerfeld> I took the latter approach (reduce the calls)
18:09:42 <rmustacc> Makes a lot of sense. I've been in the locale bits there, so if a pair of eyes would help, give me a shout.
18:09:55 <sommerfeld> but that starts to get more invasive.
18:09:57 <sommerfeld> thanks!
18:13:23 <sommerfeld> there's a whole bunch of performance issues in the regex code I spotted last week.   Every (ch < NC) ends up diving into that thread-local path.
18:13:36 <sommerfeld> https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/regex/regex2.h#LL153C5-L153C14
18:14:08 <sommerfeld> because NC depends on MB_CUR_MAX: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/regex/utils.h#L40
18:15:29 <rmustacc> yuripv: You previously were looking at tre here, weren't you? What happened at that?
18:16:25 <rmustacc> Ah, yeah. This feels like a lot of cases where making it realize this data isn't constant and caching it would be better, even if painful.
18:16:48 <sommerfeld> (and CHIN ends up being called once per NFA state per character for other dumb reasons)
18:17:17 <sommerfeld> if TRE is a drop-in replacement that would probably be a better path.
18:17:44 <rmustacc> Nothing is every quite "drop-in".
18:18:00 <sommerfeld> heh
18:18:13 <rmustacc> But it should hopefully avoid 
18:18:36 <rmustacc> Well, it just depends on the interface boundaries and whether it's designed to have support for some of the things here and how much ABI glue is needed.
18:23:41 <nbjoerg> uselocale() should burn...
18:34:01 <sommerfeld> (okay, what is everyone's favorite flamegraph generator, anyway?)
18:34:46 <richlowe> dtrace and brendan's still, I think.
18:35:00 <richlowe> I've been getting some enjoyment out of valgrind's callgrind too, but it does not flamegraph.
18:35:44 <richlowe> valgrind --tool=callgrind  <some thing to run>; callgrind_annotate --auto=yes callgrind.out.<pid>
18:36:22 <richlowe> it tells me things that the usual dtrace ticking misses, sometimes.
18:48:10 <sommerfeld> I just attached a flamegraph to https://www.illumos.org/issues/15667
18:48:11 <fenix> → BUG 15667: libc regcomp/regexec show pathological behavior for "warn:|warning:" (New) | https://code.illumos.org/c/illumos-gate/+/2860
18:50:42 <sommerfeld> ~50% of the profile is in _mb_cur_max; most of that is in uselocale()
18:55:20 <rmustacc> That's not great!
18:55:33 <rmustacc> The locale sure isn't changing through the operation.
18:57:36 <sommerfeld> Nope.   And I'm pretty sure things would break if the locale changed between regcomp and regexec.
18:57:54 <sommerfeld> so the flexibility is unnecessary..
19:03:07 <sommerfeld> (if NC isn't constant between regcomp and regexec, the dividing line between which characters are in the bitmap and which are in the array shifts)
19:05:20 <richlowe> definitely intuitively reasonable
19:05:29 <richlowe> I would hope the standards say that, too, but...
21:12:44 <sommerfeld> "If, when regexec() is called, the locale is different from when the regular expression was compiled, the result is undefined.".  https://pubs.opengroup.org/onlinepubs/009696899/functions/regcomp.html
21:17:45 <sommerfeld> so, yeah, leave room for the implementor to cache things in the compiled regexp