I feel like we could have not dboot today if loader left us in the right mode and just did ELF

I thought UEFI allowed long mode applications already

jclulow that is true.

[illumos-gate] 15637 cstyle common/devid/devid_scsi.c -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 15636 fix scsi inquiry page 83 warnings -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 15638 panic in scsi_hba_ioctl() -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 15591 idmap becomes non-functional after system memory shortage -- Gordon Ross <gwr⊙rc>

[illumos-gate] 15592 SMB should check taskq_dispatch returns -- Gordon Ross <gwr⊙rc>

[illumos-gate] 15684 ficl: remove duplicate target 'all' -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 14380 pam_modules: build errors with gcc 11 -- Toomas Soome <tsoome⊙mc>

with 14380, my gcc 11 branch is now empty.

[illumos-gate] 15673 acpica: storing the address of local variable -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 15596 SMB should export a header for kstats -- Gordon Ross <gwr⊙nc>

[illumos-gate] 15598 Allow dtrace SET_ERROR probes in libfksmbsrv -- Gordon Ross <gordon.ross⊙tc>

tsoome - congratulations! You reminded me that I do have the things ready for creating an illumos gcc12..

er, 13..

13 is the one everyone is excited about

Oh yes, and I think it is what most parties are agreed on as the next shadow target. I just forgot briefly

Thank you richlowe -- I was curious what I replace gcc7 with for the shadow.

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)

when you say "faster thread-local storage" do you mean actual TLS? and __thread?

No. uselocale() uses tsdalloc.

So we need to see what tsd index it actually gets.

Yes, true thread-local storage.

it works we use it in a small handful of places

So what key index does it get?

I don't understand the question

why does it need a key-index if it's using real TLS?

It's not.

no, sommerfeld is asking if it _could_

Sorry, I misunderstood. I took that to be could tsdalloc() be faster. Not a different mechanism.

Is uselocale() showing up in a flamegraph?

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.

so it would be a _nice_ thing if the access to TLS was abstracted so anyone in a similar hole could dodge it.

rather than the naked global data __thread we find in libses and co

(but global data sucks anyway, so...)

haven't done a flamegraph but the preliminary profiling I did showed it getting called 10+ times per input character for the sample regexp.

and tweaks to avoid those calls led to a significant speedup.

sommerfeld: That's... a lot.

yes.

We should probably reduce the number of calls there. It definitely hasn't been looked at in anger in this way sometimes.

I guess I wonder if it's going to be about reducing the cost or if we can reduce the calls.

I took the latter approach (reduce the calls)

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.

but that starts to get more invasive.

thanks!

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.

because NC depends on MB_CUR_MAX: github.com/illumos/illumos-gate/blo…src/lib/libc/port/regex/utils.h#L40

yuripv: You previously were looking at tre here, weren't you? What happened at that?

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.

(and CHIN ends up being called once per NFA state per character for other dumb reasons)

if TRE is a drop-in replacement that would probably be a better path.

Nothing is every quite "drop-in".

heh

But it should hopefully avoid

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.

uselocale() should burn...

(okay, what is everyone's favorite flamegraph generator, anyway?)

dtrace and brendan's still, I think.

I've been getting some enjoyment out of valgrind's callgrind too, but it does not flamegraph.

valgrind --tool=callgrind <some thing to run>; callgrind_annotate --auto=yes callgrind.out.<pid>

it tells me things that the usual dtrace ticking misses, sometimes.

I just attached a flamegraph to illumos.org/issues/15667

→ BUG 15667: libc regcomp/regexec show pathological behavior for "warn:|warning:" (New) | code.illumos.org/c/illumos-gate/+/2860

~50% of the profile is in _mb_cur_max; most of that is in uselocale()

That's not great!

The locale sure isn't changing through the operation.

Nope. And I'm pretty sure things would break if the locale changed between regcomp and regexec.

so the flexibility is unnecessary..

(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)

definitely intuitively reasonable

I would hope the standards say that, too, but...

"If, when regexec() is called, the locale is different from when the regular expression was compiled, the result is undefined.". pubs.opengroup.org/onlinepubs/009696899/functions/regcomp.html

so, yeah, leave room for the implementor to cache things in the compiled regexp