Date: Mon, 18 Mar 2024 01:56:30 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: "Drew Gallatin" <gallatin@freebsd.org> Cc: "Nuno Teixeira" <eduardo@freebsd.org>, tuexen@freebsd.org, garyj@gmx.de, current@freebsd.org, net@freebsd.org, "Randall Stewart" <rrs@freebsd.org> Subject: Re: Request for Testing: TCP RACK Message-ID: <20240318015630.ad95863f2f4d52e779ff0af5@dec.sakura.ne.jp> In-Reply-To: <fe9097f3-532d-4569-880b-a8a672ad8384@app.fastmail.com> References: <42C327BD-6CE4-43AA-A1AE-3BEC08D623DB@freebsd.org> <78D1FF09-71A3-4486-B934-D8332F54B237@freebsd.org> <20240316104053.20bef8c2@ernst.home> <CAFDf7UKT=FYsaXRacwsnjDkYUjT4_1QnHynWAc67yxQS8XA0Yw@mail.gmail.com> <20240316115128.33d11f7b@ernst.home> <CAFDf7U%2BBgyw2e1hJySt-4GTX3=qn6LX7B2Ebzcmvr%2BD6MJqfpg@mail.gmail.com> <7367F29A-D52B-4828-B79A-AA2667E81E7D@freebsd.org> <CAFDf7UKRLpBt%2B11GmWO5p0b-L9ZMve6MyCxRUuVm32EBZY0MWA@mail.gmail.com> <BB57B7CC-1506-4B4C-8A04-26F67DE30EDA@freebsd.org> <CAFDf7ULtN9owoH-ns2OfR6ZhypNGxuNzkQbb2P9zR8ceFgaj5A@mail.gmail.com> <4FF534F6-B35D-4596-8D1E-226AD1347AC8@freebsd.org> <CAFDf7U%2BAjfeY%2Bqjq%2B-R71w5i1pRoxQdOmqJ9w4s1U13AA8-duA@mail.gmail.com> <C5D50314-4B0C-42F6-AA67-B5A32A4BA335@freebsd.org> <CAFDf7UKL6vtKo1Mn9Vw_5OD9Xubuw%2BdgS83WKwsiTUaXHs8D6Q@mail.gmail.com> <6e795e9c-8de4-4e02-9a96-8fabfaa4e66f@app.fastmail.com> <fe9097f3-532d-4569-880b-a8a672ad8384@app.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 17 Mar 2024 11:40:54 -0400 "Drew Gallatin" <gallatin@freebsd.org> wrote: > Resending with the patch as an attachment. > > Drew > > On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote: > > 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 Controlled via RW or RWTUN sysctl/tunable? -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240318015630.ad95863f2f4d52e779ff0af5>