In D60392#1385109, @jamie wrote:

I don't see you on the committer list - do you want me to commit this for you?

I don't see you on the committer list - do you want me to commit this for you?

Rename flags.

In D60384#1385022, @jtranoleary_google.com wrote:

This patch and the two that follow it fix boot panics caused by gve on some ARM images which don't have https://reviews.freebsd.org/D59476 . gve fails to attach properly due to DMA issues and then panics when trying to unwind allocations due to null pointer dereferences.

Expose all of the LINUX_SCHED* policy constants

Where is the include loop exactly? I can't see it. IMO we should try to fix that instead of introducing a new header.

Different cloner drivers are quite inconsistent with each other about which sysinit subsystem they belong to. Some further cleanup here would be great, here I am just trying to minimally fix a panic I see when running the test suite with the linuxulator loaded.

This patch and the two that follow it fix boot panics caused by gve on some ARM images which don't have https://reviews.freebsd.org/D59476 . gve fails to attach properly due to DMA issues and then panics when trying to unwind allocations due to null pointer dereferences.

Tested the counter version on Zen 6 (1024 CPUs), hwpmc.ko only, with machdep.panic_on_nmi=255, running pmcstat with scimark4: 20 runs with -S ibs-fetch -S ibs-op, 4 with the order reversed, 5 op only and 5 fetch only. All 34 runs had 0 unknown NMIs and kern.hwpmc.stats.intr_ignored stayed at 0. For comparison, the stock module gives about 180 unclaimed NMIs per 8 runs with both events.

Does it become possible that one of these intermediate NMIs could arrive with both events, thus needing an additional credit?

Count owed NMIs and cap the count (IBS_NMI_CREDIT_MAX), per mhorne's review.

I don't know much about this, but @bofh does... so OK by me.

In D60271#1383119, @alc wrote:

Yes. I would test GENERIC-NODEBUG kernels without and with this patch. I have /etc/src.conf:

WITHOUT_LLVM_ASSERTIONS=yes
#
WITH_CLEAN=yes
WITH_MALLOC_PRODUCTION=yes

I run:

#!/bin/csh
cd /usr/src
rm -fr /usr/obj/usr/src
while ( 1 )
    date
    sysctl vm.pmap vm.reserv vm.stats.vm.v_vm_faults
    time make -j16 buildworld > & /dev/null 
    rm -fr /usr/obj/usr/src
end

with -j adjusted for the machine and the script's output redirected to a log.

Hello @ali_mashtizadeh.com @mhorne, could you review that implementation? It's been a while since I submitted it and there hasn't been a review yet.

Yeah, that's true. I can also imagine a program that would modify a string as a member of struct jail before passing to jail(2). :(

It looks like the build failure with both LTO and DTrace enabled was reported upstream some time ago.

In D60072#1379055, @markj wrote:

I suspect that using pm_active to store hart IDs instead of CPU IDs is too clever and will cause more problems down the road. We should instead store CPU IDs there and make the SBI routines handle translation to hart IDs.

LGTM, with one question.