re: CVS commit: src/share/mk
> what sort of testing did you do with this change? simply removing > it breaks the build. and trying to fix it otherwise is hard. see > only a month ago: huh. my build *did* complete. so something else has changed in the last month or so to fix this... sorry for the noise. .mrg.
re: CVS commit: src/share/mk
"Maya Rashish" writes: > Module Name: src > Committed By: maya > Date: Sat Feb 8 21:16:53 UTC 2020 > > Modified Files: > src/share/mk: sys.mk > > Log Message: > Don't special case aarch64 and add -fomit-frame-pointer to builds. > > This behaviour is probably due to a past behaviour of clang, where it > always emitted frame pointer code. > This is no longer true for clang on netbsd, and I don't think it was true > for GCC. > > Meanwhile, this flag bleeds into pkgsrc where it breaks random packages, > requiring workarounds like lang/ruby*-base/hacks.mk. what sort of testing did you do with this change? simply removing it breaks the build. and trying to fix it otherwise is hard. see only a month ago: revision 1.142 date: 2020-01-08 14:04:24 -0800; author: christos; state: Exp; lines: +1 -1; commitid: NcvOnC9CgM4A5WRB; Back out previous. This has no chance to work unless the make variable parsing is not changed do that instead of scanning for a single character delim ':', it scans for "?:". This is because !empty(COMPILE.c:M*-pg*) contains a ':'. revision 1.141 date: 2020-01-07 20:15:45 -0800; author: christos; state: Exp; lines: +2 -2; commitid: U2dp6ScXDBHOaQRB; tweak the DBG rule that -fomit-frame-pointer for aarch64 when profiling (because the compiler complains), to use a match with the compile flags and *pg*, instead of using a match to a target suffix (which is NetBSD build-specific). Pointed out by phone@. .mrg.
Re: CVS commit: src/sys
> On Feb 8, 2020, at 12:45 PM, Andrew Doran wrote: > > Bit concerning that we're growing a ton of kthreads in the network stack (my > test system now has something like 700 kthreads total) but I'm less worried > about that and moreso that a lot of these seem to be in the kernel RT range > and will therefore cause kernel preemptions when triggered. > > For something like a link state change that's no biggie but I'm not fond of > the idea of bulk wire & protcol processing needing mi_switch() + kpreempt(). > Way back when we made a concious decision not copy the design pattern our > sister project went with on this front. Maybe it is the right way to go now > but I think that should also be a concious design decision. Roger that. I agree with you -- I would prefer "regular" stuff to continue using softints. For some other stuff, though, we've made the policy decision that softints can't block for anything other than an adaptive mutex, which is fine... this particular case sends a message to the routing socket, which requires gathering interface statistics, which blocks on something other than an adaptive mutex. I'm not a fan of the workqueue interface, and I have something better sitting unfinished in my Bucket Of Stuff I'm Working On ... a generalized "task" interface originally written-but-not-finished by Taylor that uses either thread pools or softints to do the work... so at least the threads won't linger around in the "mostly idle" case. -- thorpej
Re: CVS commit: src/sys
On Thu, Feb 06, 2020 at 11:30:20PM +, Jason R Thorpe wrote: > Modified Files: > src/sys/net: if.c if.h > src/sys/netinet: ip_carp.c > > Log Message: > Perform link state change processing on a work queue, rather than in a > softint. Thinking out loud more than anything else: Bit concerning that we're growing a ton of kthreads in the network stack (my test system now has something like 700 kthreads total) but I'm less worried about that and moreso that a lot of these seem to be in the kernel RT range and will therefore cause kernel preemptions when triggered. For something like a link state change that's no biggie but I'm not fond of the idea of bulk wire & protcol processing needing mi_switch() + kpreempt(). Way back when we made a concious decision not copy the design pattern our sister project went with on this front. Maybe it is the right way to go now but I think that should also be a concious design decision. Andrew
