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
