Smithx10: unfortuantely, the way that aggrs work with mac for performance reasons, it's not a simple fix

maybe 1 day... link aggrs will support lldp :P

hello. is bhyve in illumos-gate now? i see the manpage is on illumos.org but i'm not sure branch those come from...

yes, for a long time

FYI: I updated Gerrit to 3.9.1 -- let me know if you see anything weird.

is the RTI queue being processed?

Trying to statically compile a go binary, GOOS=illumos CGO_ENABLED=1 go build -ldflags "-linkmode 'external' -extldflags '-static'" -v . results in ld: fatal: library -lsocket: not found and a few others

maybe the '-static' bit?

AFAIK, you can't statically link any of the system libraries

:( Was trying to write a small tool to take out interfaces from aggregations and get the LLDP info and put them back.... was gonna grab the lldp info with github.com/google/gopacket

all the CNs dont have libpcap, was hoping to just make it static*

we don't provide static versions of any system library

The linux instructions won't work, you can't create a static binary

you should be able to statically link libpcap, but dynamically link libsocket

but I can't tell you how to do that through the go soup unfortunately

But you might try something like:

richlowe that should probably work

go build -ldflags "-linkmode 'external' -extldflags '-Wl,-Bstatic -lpcap -Wl,-Bdynamic'"

which should only pick up libpcap statically

ptribble: you are the man :)

ping @andyf re fenix illumos#15998 ?

FEATURE 15998: Increase the rate and efficiency of vm_pageout (Closed)

↳ illumos.org/issues/15998 | code.illumos.org/c/illumos-gate/+/1272

In the SmartOS version, there are several cv_signal() calls in usr/src/uts/common/vm/vm_page.c that got converted to cv_broadcast.

(And they got hidden by the redefined-for-upstream WAKE_PAGEOUT_SCANNER() macro.)

I'm curious, should those (as well as one in usr/src/uts/i86pc/vm/vm_machdep.c:3549) get upgraded to cv_broadcast?

Presumably they were changed in SmartOS because of the multiple scanning hands?

But isn't 15998 introducing those same multiple scanning hands?

Hmm, maybe I confused those bits then. Sorry.

It feels like either missing review feedback ("you don't need to cv_broadcast() there!") **OR** missing code changes.

"missing review feedback" ==> something internal that should've been documented on gerrit.

@ptribble actually hmmm ld.so.1: foo: fatal: libpcap.so.0: open failed: No such file or directory it made the binary but when I went to run it on the other box still got libpcap not found

On a related note to 15998, should fenix illumos#13567 be closed now?

FEATURE 15998: Increase the rate and efficiency of vm_pageout (Closed)

↳ illumos.org/issues/15998 | code.illumos.org/c/illumos-gate/+/1272

wrong guess, fenix. how about 13567 ?

or illumos.org/issues/13567 ?

→ BUG 13567: maxpgio is too low for modern systems (New)

Smithx10: why not just install libpcap on that machine? (possibly in a non-standard location, with LD_LIBRARY_PATH to find it if need be)

Smithx10: you can get the exact gcc command line it's issuing with

go build -ldflags "-linkmode 'external' -extldflags '-lssp -Wl,-Bstatic -lpcap -Wl,-Bdynamic' -v"

which might show if it's also pulling in libpcap a second time

Ah. Let me look

[illumos-gate] 16147 OpenZFS ZTS: normalize on use of `sync_pool` and `sync_all_pools` -- Allan Jude <allan⊙kc>

Yep, there's the extra "-L" "/opt/local/lib" "-lpcap" so you need to make sure that it doesn't put that first "-lpcap" into the link line

@sommerfeld we could, I suppose. @jclulow, since he filed the bug, is likely the authority of this.

@ptribble i wonder if its getting that from github.com/google/gopacket/blob/master/pcap/pcap_unix.go#L26

Smithx10: I guess it will put those LDFLAGS first, then the extra flags you specify with extldflags, so I can imagine removing -lpcap from there ought to work

danmcd: on the cv_broadcast vs cv_signal thing, it may be more of a tuning issue than one of correctness. When memory is low, do you want to poke one scanner or all of them? (as an aside, it appears that the underling primitives will do FIFO wakeups among threads of the same priority so it should round-robin amongst all the scanner threads). Probably better to be consistent about it, though.

richlowe, sommerfeld: I'm not sure about closing 13567, to be honest. I am not sure if we've addressed the uses of maxpgio outside of the pageout rate stuff?

Or the async_list_size thing

I've put a note in the ticket there

[illumos-gate] 16148 zfs-tests: enospc_002_pos is failing -- Brian Behlendorf <behlendorf1⊙lg>

jclulow: thanks for updating the bug.

You're welcome!

@jbk so it looks like I am able to at least read the frames from ToR on the interfaces in the aggregations