Re: Request for Testing: TCP RACK
- Reply: Drew Gallatin: "Re: Request for Testing: TCP RACK"
- Reply: tuexen_a_freebsd.org: "Re: Request for Testing: TCP RACK"
- Reply: Nuno Teixeira : "Re: Request for Testing: TCP RACK"
- In reply to: Nuno Teixeira : "Re: Request for Testing: TCP RACK"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 17 Mar 2024 15:39:06 UTC
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: diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c index e9a16cd0b36e..54b540c97123 100644 --- a/sys/kern/subr_trap.c +++ b/sys/kern/subr_trap.c @@ -138,7 +138,7 @@ userret(struct thread *td, struct trapframe *frame) * Software Timer Support for Network Processing" * by Mohit Aron and Peter Druschel. */ - tcp_hpts_softclock(); + /*tcp_hpts_softclock();*/ /* * Let the scheduler adjust our priority etc. */ If that fixes it, I suspect we should either make this hook optional for casual users of tcp_hpts(), or add some kind of "last called" timestamp to prevent it being called over and over and over on workloads which are syscall heavy. Note that for non-casual users of hpts (like Netflix, with hundreds of thousands of TCP connections managed by hpts), this call is a huge win, so I think we'd prefer that it remain in some form. Drew