> > only now test that it does not on my local box :)
> The patch still causes access to all cpu's cachelines on each userret.
> It would be much better to inc/check the threshold and only schedule the
> call when exceeded. Then the call can occur in some dedicated context,
> l
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/publicati
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
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
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
This sounds like a good plan to me
On Thu, Apr 6, 2023, at 2:34 PM, Gleb Smirnoff wrote:
> Hi,
>
> recently we had several drivers marked with IFF_KNOWSEPOCH
> which reminded me that this flag was supposed to be temporary.
>
> Here is the change that introduced it e87c4940156. It was
> caused
