- User Since
- Jun 4 2014, 10:38 AM (235 w, 5 d)
Sat, Dec 8
Fri, Dec 7
Wed, Dec 5
can you grab a flamegraph from such a test? also, can you compare this against https://reviews.freebsd.org/D17992 ?
Sat, Dec 1
I did basic tests with changing the alignment of src and slowdowns were very small compared to similarly misaligned dst, at least on EPYC. I may take a closer look later.
Fri, Nov 30
Thu, Nov 29
Wed, Nov 28
once more i don't have a full picture so can't give a proper review.
Fri, Nov 23
Thu, Nov 22
- remove now spurious cv_broadcast(&p->p_pwait);
Wed, Nov 21
- fix fork
Tue, Nov 20
So both ring and swi kicking code are significant players. I think a simple and probably good enough solution would just add more rings, perhaps based on the number of hardware threads. Assuming the traffic is hashed to distribute among them, the rings could mostly remain unshared with unrelated threads. Sending out of the traffic would just combine data from all rings. Kicking can also be avoided in a simple manner. You can add a var signifying the frequency of wakeups. The increase the frequency based on the traffic and past certain threshold you stop kicking swi. It has to decay so that if there is no traffic, the code goes back to wakeups once a second (or whatever).
Sun, Nov 18
So I retested with your change. a failing build indeed is fixed. Perhaps my original change had a typo or compatible. Thanks.
Are you sure that on your box a *failing* -DNO_CLEAN starts building again with this change? Are you using meta-mode? I had a similar change locally and the build kept failing anyway, no meta-mode though.
Fri, Nov 16
- address feedback
- drop killpg changes
Thu, Nov 15
yes. these patches are stale and kind of crap. I have a WIP replacement which I'llprobalby post in a new review, we will see.
I have no doubt there is an improvement, just saying it is still slower than it can be and unless this uncovered a new major bottleneck, the ring manipulation is the new hotspot.
Wed, Nov 14
I think the approach taken here is iffy. Basic problem with this is that even if there is no lock contention anymore, you are still suffering from bouncing cache lines. Also swi_sched probably does not appreciate being called very often.
Tue, Nov 13
Nov 8 2018
Nov 6 2018
- address feedback
- regen against head
- i did not change the condition in proc_realparent as it goes way over the 80 char limit
Nov 4 2018
I don't think the same problem is a concern for ps/top, so it can be discussed further in a different review. I can simply drop killpg conversion from the patchset (and remove the spurious curly braces).
killpg is already unreliable. if the child is spotted as PRS_NEW it will be explicitly omitted, so I don't think this constitutes a regression in functionality