Re: git: e34ea0196f44 - main - tcp: clear all TCP timers in tcp_timer_stop() when in callout
Hi!
This commit is supposed to fix a problem we do not have a reproducer for.
The problem was that sometimes a TCP connection enters tcp_discardcb()
with a scheduled timer. A temporary patch 57e27ff07aff was committed
to mask the problem. This patch is supposed to fix the root cause.
However, again, we were not able to reproduce the problem reliably
and thus were not able to test that the just committed patch indeed
fixes the root cause. But the assertion is put back to tcp_discardcb().
In case you got a panic in tcp_discardcb(), please email me ASAP.
On Mon, Mar 18, 2024 at 08:57:10PM +, Gleb Smirnoff wrote:
T> The branch main has been updated by glebius:
T>
T> URL:
https://cgit.FreeBSD.org/src/commit/?id=e34ea0196f4497d3f3939025aff3a89ee77b652e
T>
T> commit e34ea0196f4497d3f3939025aff3a89ee77b652e
T> Author: Gleb Smirnoff
T> AuthorDate: 2024-03-18 20:57:00 +
T> Commit: Gleb Smirnoff
T> CommitDate: 2024-03-18 20:57:00 +
T>
T> tcp: clear all TCP timers in tcp_timer_stop() when in callout
T>
T> When a TCP callout decides to disable self, e.g. tcp_timer_2msl() calling
T> tcp_close(), we must also clear all other possible timers. Otherwise,
T> upon return, the callout would be scheduled again in tcp_timer_enter().
T>
T> Revert 57e27ff07aff, which was a temporary partial revert of otherwise
T> correct 62d47d73b7eb, that exposed the problem being fixed now. Add an
T> extra assertion in tcp_timer_enter() to check we aren't arming callout
for
T> a closed connection.
T>
T> Reviewed by:rscheff
T> ---
T> sys/netinet/tcp_subr.c | 3 +--
T> sys/netinet/tcp_timer.c | 6 --
T> 2 files changed, 5 insertions(+), 4 deletions(-)
T>
T> diff --git a/sys/netinet/tcp_subr.c b/sys/netinet/tcp_subr.c
T> index f618bc1ba04b..a6f84c297688 100644
T> --- a/sys/netinet/tcp_subr.c
T> +++ b/sys/netinet/tcp_subr.c
T> @@ -2395,10 +2395,9 @@ tcp_discardcb(struct tcpcb *tp)
T> #endif
T>
T> INP_WLOCK_ASSERT(inp);
T> +MPASS(!callout_active(>t_callout));
T> MPASS(TAILQ_EMPTY(>snd_holes));
T>
T> -tcp_timer_stop(tp);
T> -
T> /* free the reassembly queue, if any */
T> tcp_reass_flush(tp);
T>
T> diff --git a/sys/netinet/tcp_timer.c b/sys/netinet/tcp_timer.c
T> index ed50659abf8e..785f68be5621 100644
T> --- a/sys/netinet/tcp_timer.c
T> +++ b/sys/netinet/tcp_timer.c
T> @@ -881,6 +881,7 @@ tcp_timer_enter(void *xtp)
T> if (tp_valid) {
T> tcp_bblog_timer(tp, which, TT_PROCESSED, 0);
T> if ((which = tcp_timer_next(tp, )) != TT_N) {
T> +MPASS(tp->t_state > TCPS_CLOSED);
T> callout_reset_sbt_on(>t_callout,
T> tp->t_timers[which], precision, tcp_timer_enter,
T> tp, inp_to_cpuid(inp), C_ABSOLUTE);
T> @@ -939,8 +940,7 @@ tcp_timer_active(struct tcpcb *tp, tt_which which)
T> /*
T> * Stop all timers associated with tcpcb.
T> *
T> - * Called only on tcpcb destruction. The tcpcb shall already be dropped
from
T> - * the pcb lookup database and socket is not losing the last reference.
T> + * Called when tcpcb moves to TCPS_CLOSED.
T> *
T> * XXXGL: unfortunately our callout(9) is not able to fully stop a locked
T> * callout even when only two threads are involved: the callout itself and
the
T> @@ -963,6 +963,8 @@ tcp_timer_stop(struct tcpcb *tp)
T>
T> stopped = callout_stop(>t_callout);
T> MPASS(stopped == 0);
T> +for (tt_which i = 0; i < TT_N; i++)
T> +tp->t_timers[i] = SBT_MAX;
T> } else while(__predict_false(callout_stop(>t_callout) == 0)) {
T> INP_WUNLOCK(inp);
T> kern_yield(PRI_UNCHANGED);
--
Gleb Smirnoff
Re: Request for Testing: TCP RACK
No. The goal is to run on every return to userspace for every thread. Drew On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote: > On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: > > I got the idea from > > https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf > > The gist is that the TCP pacing stuff needs to run frequently, and > > rather than run it out of a clock interrupt, its more efficient to run > > it out of a system call context at just the point where we return to > > userspace and the cache is trashed anyway. The current implementation > > is fine for our workload, but probably not idea for a generic system. > > Especially one where something is banging on system calls. > > > > Ast's could be the right tool for this, but I'm super unfamiliar with > > them, and I can't find any docs on them. > > > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to > > what's happening here? > This call would need some AST number added, and then it registers the > ast to run on next return to userspace, for the current thread. > > Is it enough? > > > > Drew > > > > > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: > > > On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > > > > On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: > > > > > > > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > > > > >> > > > > >> Hello all! > > > > >> > > > > >> It works just fine! > > > > >> System performance is OK. > > > > >> Using patch on main-n268841-b0aaf8beb126(-dirty). > > > > >> > > > > >> --- > > > > >> net.inet.tcp.functions_available: > > > > >> Stack D Alias > > > > >> PCB count > > > > >> freebsd freebsd 0 > > > > >> rack* rack 38 > > > > >> --- > > > > >> > > > > >> It would be so nice that we can have a sysctl tunnable for this patch > > > > >> so we could do more tests without recompiling kernel. > > > > > Thanks for testing! > > > > > > > > > > @gallatin: can you come up with a patch that is acceptable for Netflix > > > > > and allows to mitigate the performance regression. > > > > > > > > Ideally, tcphpts could enable this automatically when it starts to be > > > > used (enough?), but a sysctl could select auto/on/off. > > > There is already a well-known mechanism to request execution of the > > > specific function on return to userspace, namely AST. The difference > > > with the current hack is that the execution is requested for one callback > > > in the context of the specific thread. > > > > > > Still, it might be worth a try to use it; what is the reason to hit a > > > thread > > > that does not do networking, with TCP processing? > > > > > > > > > > > Mike > > > > > > > > > Best regards > > > > > Michael > > > > >> > > > > >> Thanks all! > > > > >> Really happy here :) > > > > >> > > > > >> Cheers, > > > > >> > > > > >> Nuno Teixeira escreveu (domingo, 17/03/2024 > > > > >> à(s) 20:26): > > > > >>> > > > > >>> Hello, > > > > >>> > > > > I don't have the full context, but it seems like the complaint is > > > > a performance regression in bonnie++ and perhaps other things when > > > > tcp_hpts is loaded, even when it is not used. Is that correct? > > > > > > > > If so, I suspect its because we drive the tcp_hpts_softclock() > > > > routine from userret(), in order to avoid tons of timer interrupts > > > > and context switches. To test this theory, you could apply a > > > > patch like: > > > > >>> > > > > >>> It's affecting overall system performance, bonnie was just a way to > > > > >>> get some numbers to compare. > > > > >>> > > > > >>> Tomorrow I will test patch. > > > > >>> > > > > >>> Thanks! > > > > >>> > > > > >>> -- > > > > >>> Nuno Teixeira > > > > >>> FreeBSD Committer (ports) > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Nuno Teixeira > > > > >> FreeBSD Committer (ports) > > > > > > > >
Re: Request for Testing: TCP RACK
On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: > I got the idea from > https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf > The gist is that the TCP pacing stuff needs to run frequently, and > rather than run it out of a clock interrupt, its more efficient to run > it out of a system call context at just the point where we return to > userspace and the cache is trashed anyway. The current implementation > is fine for our workload, but probably not idea for a generic system. > Especially one where something is banging on system calls. > > Ast's could be the right tool for this, but I'm super unfamiliar with > them, and I can't find any docs on them. > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to > what's happening here? This call would need some AST number added, and then it registers the ast to run on next return to userspace, for the current thread. Is it enough? > > Drew > > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: > > On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > > > On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: > > > > > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > > > >> > > > >> Hello all! > > > >> > > > >> It works just fine! > > > >> System performance is OK. > > > >> Using patch on main-n268841-b0aaf8beb126(-dirty). > > > >> > > > >> --- > > > >> net.inet.tcp.functions_available: > > > >> Stack D AliasPCB > > > >> count > > > >> freebsd freebsd 0 > > > >> rack* rack 38 > > > >> --- > > > >> > > > >> It would be so nice that we can have a sysctl tunnable for this patch > > > >> so we could do more tests without recompiling kernel. > > > > Thanks for testing! > > > > > > > > @gallatin: can you come up with a patch that is acceptable for Netflix > > > > and allows to mitigate the performance regression. > > > > > > Ideally, tcphpts could enable this automatically when it starts to be > > > used (enough?), but a sysctl could select auto/on/off. > > There is already a well-known mechanism to request execution of the > > specific function on return to userspace, namely AST. The difference > > with the current hack is that the execution is requested for one callback > > in the context of the specific thread. > > > > Still, it might be worth a try to use it; what is the reason to hit a thread > > that does not do networking, with TCP processing? > > > > > > > > Mike > > > > > > > Best regards > > > > Michael > > > >> > > > >> Thanks all! > > > >> Really happy here :) > > > >> > > > >> Cheers, > > > >> > > > >> Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) > > > >> 20:26): > > > >>> > > > >>> Hello, > > > >>> > > > I don't have the full context, but it seems like the complaint is a > > > performance regression in bonnie++ and perhaps other things when > > > tcp_hpts is loaded, even when it is not used. Is that correct? > > > > > > If so, I suspect its because we drive the tcp_hpts_softclock() > > > routine from userret(), in order to avoid tons of timer interrupts > > > and context switches. To test this theory, you could apply a patch > > > like: > > > >>> > > > >>> It's affecting overall system performance, bonnie was just a way to > > > >>> get some numbers to compare. > > > >>> > > > >>> Tomorrow I will test patch. > > > >>> > > > >>> Thanks! > > > >>> > > > >>> -- > > > >>> Nuno Teixeira > > > >>> FreeBSD Committer (ports) > > > >> > > > >> > > > >> > > > >> -- > > > >> Nuno Teixeira > > > >> FreeBSD Committer (ports) > > > > >
Re: Request for Testing: TCP RACK
I got the idea from https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf The gist is that the TCP pacing stuff needs to run frequently, and rather than run it out of a clock interrupt, its more efficient to run it out of a system call context at just the point where we return to userspace and the cache is trashed anyway. The current implementation is fine for our workload, but probably not idea for a generic system. Especially one where something is banging on system calls. Ast's could be the right tool for this, but I'm super unfamiliar with them, and I can't find any docs on them. Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to what's happening here? Drew On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: > On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > > On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: > > > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > > >> > > >> Hello all! > > >> > > >> It works just fine! > > >> System performance is OK. > > >> Using patch on main-n268841-b0aaf8beb126(-dirty). > > >> > > >> --- > > >> net.inet.tcp.functions_available: > > >> Stack D AliasPCB > > >> count > > >> freebsd freebsd 0 > > >> rack* rack 38 > > >> --- > > >> > > >> It would be so nice that we can have a sysctl tunnable for this patch > > >> so we could do more tests without recompiling kernel. > > > Thanks for testing! > > > > > > @gallatin: can you come up with a patch that is acceptable for Netflix > > > and allows to mitigate the performance regression. > > > > Ideally, tcphpts could enable this automatically when it starts to be > > used (enough?), but a sysctl could select auto/on/off. > There is already a well-known mechanism to request execution of the > specific function on return to userspace, namely AST. The difference > with the current hack is that the execution is requested for one callback > in the context of the specific thread. > > Still, it might be worth a try to use it; what is the reason to hit a thread > that does not do networking, with TCP processing? > > > > > Mike > > > > > Best regards > > > Michael > > >> > > >> Thanks all! > > >> Really happy here :) > > >> > > >> Cheers, > > >> > > >> Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) > > >> 20:26): > > >>> > > >>> Hello, > > >>> > > I don't have the full context, but it seems like the complaint is a > > performance regression in bonnie++ and perhaps other things when > > tcp_hpts is loaded, even when it is not used. Is that correct? > > > > If so, I suspect its because we drive the tcp_hpts_softclock() routine > > from userret(), in order to avoid tons of timer interrupts and context > > switches. To test this theory, you could apply a patch like: > > >>> > > >>> It's affecting overall system performance, bonnie was just a way to > > >>> get some numbers to compare. > > >>> > > >>> Tomorrow I will test patch. > > >>> > > >>> Thanks! > > >>> > > >>> -- > > >>> Nuno Teixeira > > >>> FreeBSD Committer (ports) > > >> > > >> > > >> > > >> -- > > >> Nuno Teixeira > > >> FreeBSD Committer (ports) > > >
Re: Request for Testing: TCP RACK
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > >> > >> Hello all! > >> > >> It works just fine! > >> System performance is OK. > >> Using patch on main-n268841-b0aaf8beb126(-dirty). > >> > >> --- > >> net.inet.tcp.functions_available: > >> Stack D AliasPCB > >> count > >> freebsd freebsd 0 > >> rack* rack 38 > >> --- > >> > >> It would be so nice that we can have a sysctl tunnable for this patch > >> so we could do more tests without recompiling kernel. > > Thanks for testing! > > > > @gallatin: can you come up with a patch that is acceptable for Netflix > > and allows to mitigate the performance regression. > > Ideally, tcphpts could enable this automatically when it starts to be > used (enough?), but a sysctl could select auto/on/off. There is already a well-known mechanism to request execution of the specific function on return to userspace, namely AST. The difference with the current hack is that the execution is requested for one callback in the context of the specific thread. Still, it might be worth a try to use it; what is the reason to hit a thread that does not do networking, with TCP processing? > > Mike > > > Best regards > > Michael > >> > >> Thanks all! > >> Really happy here :) > >> > >> Cheers, > >> > >> Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) > >> 20:26): > >>> > >>> Hello, > >>> > I don't have the full context, but it seems like the complaint is a > performance regression in bonnie++ and perhaps other things when > tcp_hpts is loaded, even when it is not used. Is that correct? > > If so, I suspect its because we drive the tcp_hpts_softclock() routine > from userret(), in order to avoid tons of timer interrupts and context > switches. To test this theory, you could apply a patch like: > >>> > >>> It's affecting overall system performance, bonnie was just a way to > >>> get some numbers to compare. > >>> > >>> Tomorrow I will test patch. > >>> > >>> Thanks! > >>> > >>> -- > >>> Nuno Teixeira > >>> FreeBSD Committer (ports) > >> > >> > >> > >> -- > >> Nuno Teixeira > >> FreeBSD Committer (ports) >
kernel= , kern.module_path= , and loader menu selections: how to have it always find the matching, say, nfsd.ko (same directory as the kernel)
I'm using an aarch64 environment as the example context for this note. I have instances of the various PkgBase kernels and one or more personal kernel builds. Currently: # ls -Tlod /boot/kernel*/nfsd* -r--r--r-- 1 root wheel - 401600 Mar 17 18:45:35 2024 /boot/kernel.CA76-NODBG.good/nfsd.ko -r--r--r-- 1 root wheel - 401600 Mar 17 18:45:35 2024 /boot/kernel.CA76-NODBG/nfsd.ko -r--r--r-- 1 root wheel - 388624 Mar 15 19:18:47 2024 /boot/kernel.GENERIC-DEBUG.good/nfsd.ko -r--r--r-- 1 root wheel - 388624 Mar 15 19:18:47 2024 /boot/kernel.GENERIC-MMCCAM/nfsd.ko -r--r--r-- 1 root wheel - 425968 Mar 15 19:18:47 2024 /boot/kernel.GENERIC-NODEBUG.good/nfsd.ko -r--r--r-- 1 root wheel - 425968 Mar 15 19:18:47 2024 /boot/kernel.GENERIC-NODEBUG/nfsd.ko -r--r--r-- 1 root wheel - 388624 Mar 15 19:18:47 2024 /boot/kernel/nfsd.ko The kernel.CA76-*/ ones are my tailored builds. The others are from PkgBase. (amd64 also has a PkgBase kernel.MINIMAL/ .) I originally used loader.conf lines like the following to control what loaded by default: #kernel="kernel" #kernel="kernel.GENERIC-DEBUG.good" kernel="kernel.GENERIC-NODEBUG" #kernel="kernel.GENERIC-NODEBUG.good" #kernel="kernel.GENERIC-MMCCAM" # #kernel="kernel.CA76-DBG" #kernel="kernel.CA76-NODBG" However, I found that the /etc/rc.conf lines like: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" nfs_client_enable="YES" did not cause nfsd to load (for example). I worked around this by also having an assignment to kern.module_path : #kernel="kernel.GENERIC-DEBUG.good" #kern.module_path="/boot/kernel.GENERIC-DEBUG.good" kernel="kernel.GENERIC-NODEBUG" kern.module_path="/boot/kernel.GENERIC-NODEBUG" #kernel="kernel.GENERIC-NODEBUG.good" #kern.module_path="/boot/kernel.GENERIC-NODEBUG.good" #kernel="kernel.GENERIC-MMCCAM" #kern.module_path="/boot/kernel.GENERIC-MMCCAM" # #kernel="kernel.CA76-DBG" #kern.module_path="/boot/kernel.CA76-DBG" #kernel="kernel.CA76-NODBG" #kern.module_path="/boot/kernel.CA76-NODBG" (That suggests that kern.module_path did not automatically track the kernel= assignment.) That worked for loading the loader.conf specified default kernel and the matching nfsd . But, if, in the loader menu, I pick a different kernel, the problem returns, likely from still trying the kern.module_path from the loader.conf (?). Note: My keeping a little library of kernels around is new. I've no history to know how long the behavior that I've seen has been this way. Is there a way for it to automatically use the likes of the nfsd.ko from the same directory as the kernel in all cases, where I pick the default kernel place via loader.conf ? Do I need to do more manual steps in the loader, not just use the menu selections to override the defaults for this sufficiently to have the likes of the matching nfsd.ko load? === Mark Millard marklmi at yahoo.com
Re: Request for Testing: TCP RACK
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> ...
> >> It would be so nice that we can have a sysctl tunnable for this patch
> >> so we could do more tests without recompiling kernel.
> > Thanks for testing!
> >
> > @gallatin: can you come up with a patch that is acceptable for Netflix
> > and allows to mitigate the performance regression.
>
> Ideally, tcphpts could enable this automatically when it starts to be
> used (enough?), but a sysctl could select auto/on/off.
>
> Mike
>
Or (at some risk of over-{complicat,engineer}ing things), perhaps
sysctl/tunable for high- and low-water marks?
Peace,
david (who is quite unlikely to be writing the code, so "grain of salt")
--
David H. Wolfskill da...@catwhisker.org
Alexey Navalny was a courageous man; Putin has made him a martyr.
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: Request for Testing: TCP RACK
On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: >> >> Hello all! >> >> It works just fine! >> System performance is OK. >> Using patch on main-n268841-b0aaf8beb126(-dirty). >> >> --- >> net.inet.tcp.functions_available: >> Stack D AliasPCB count >> freebsd freebsd 0 >> rack* rack 38 >> --- >> >> It would be so nice that we can have a sysctl tunnable for this patch >> so we could do more tests without recompiling kernel. > Thanks for testing! > > @gallatin: can you come up with a patch that is acceptable for Netflix > and allows to mitigate the performance regression. Ideally, tcphpts could enable this automatically when it starts to be used (enough?), but a sysctl could select auto/on/off. Mike > Best regards > Michael >> >> Thanks all! >> Really happy here :) >> >> Cheers, >> >> Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) >> 20:26): >>> >>> Hello, >>> I don't have the full context, but it seems like the complaint is a performance regression in bonnie++ and perhaps other things when tcp_hpts is loaded, even when it is not used. Is that correct? If so, I suspect its because we drive the tcp_hpts_softclock() routine from userret(), in order to avoid tons of timer interrupts and context switches. To test this theory, you could apply a patch like: >>> >>> It's affecting overall system performance, bonnie was just a way to >>> get some numbers to compare. >>> >>> Tomorrow I will test patch. >>> >>> Thanks! >>> >>> -- >>> Nuno Teixeira >>> FreeBSD Committer (ports) >> >> >> >> -- >> Nuno Teixeira >> FreeBSD Committer (ports)
Re: Request for Testing: TCP RACK
> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > > Hello all! > > It works just fine! > System performance is OK. > Using patch on main-n268841-b0aaf8beb126(-dirty). > > --- > net.inet.tcp.functions_available: > Stack D AliasPCB count > freebsd freebsd 0 > rack* rack 38 > --- > > It would be so nice that we can have a sysctl tunnable for this patch > so we could do more tests without recompiling kernel. Thanks for testing! @gallatin: can you come up with a patch that is acceptable for Netflix and allows to mitigate the performance regression. Best regards Michael > > Thanks all! > Really happy here :) > > Cheers, > > Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) 20:26): >> >> Hello, >> >>> I don't have the full context, but it seems like the complaint is a >>> performance regression in bonnie++ and perhaps other things when tcp_hpts >>> is loaded, even when it is not used. Is that correct? >>> >>> If so, I suspect its because we drive the tcp_hpts_softclock() routine from >>> userret(), in order to avoid tons of timer interrupts and context switches. >>> To test this theory, you could apply a patch like: >> >> It's affecting overall system performance, bonnie was just a way to >> get some numbers to compare. >> >> Tomorrow I will test patch. >> >> Thanks! >> >> -- >> Nuno Teixeira >> FreeBSD Committer (ports) > > > > -- > Nuno Teixeira > FreeBSD Committer (ports)
Re: Request for Testing: TCP RACK
Hello all! It works just fine! System performance is OK. Using patch on main-n268841-b0aaf8beb126(-dirty). --- net.inet.tcp.functions_available: Stack D AliasPCB count freebsd freebsd 0 rack* rack 38 --- It would be so nice that we can have a sysctl tunnable for this patch so we could do more tests without recompiling kernel. Thanks all! Really happy here :) Cheers, Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) 20:26): > > Hello, > > > I don't have the full context, but it seems like the complaint is a > > performance regression in bonnie++ and perhaps other things when tcp_hpts > > is loaded, even when it is not used. Is that correct? > > > > If so, I suspect its because we drive the tcp_hpts_softclock() routine from > > userret(), in order to avoid tons of timer interrupts and context switches. > > To test this theory, you could apply a patch like: > > It's affecting overall system performance, bonnie was just a way to > get some numbers to compare. > > Tomorrow I will test patch. > > Thanks! > > -- > Nuno Teixeira > FreeBSD Committer (ports) -- Nuno Teixeira FreeBSD Committer (ports)
