On 20 January 2015 at 06:25, Ed Maste <ema...@freebsd.org> wrote: > On 20 January 2015 at 04:37, Hans Petter Selasky <h...@selasky.org> wrote: >> >> It is not very hard to update existing callout clients and you can do it >> too, if you need the extra bits of performance. > > Hi Hans Petter, > > The issue here is that the onus is on the one changing a KPI to > support its consumers through the transition. This doesn't necessarily > mean doing all of the work. But the KPI changes, and techniques for > adapting to them, need to be communicated very well in advance of the > change arriving. > > I appreciate that you have a patch for TCP in review now - but having > Adrian encounter a huge TCP performance regression is an unfortunate > way to discover this issue.
I'm +1 on the "think it's the right, clean solution for the callout stuff" as I've done this stuff in userland a few times and it gets hairy very quickly when you try to support multiple ways to schedule, cancel and migrate events from arbitrary CPUs. I'm -1 on the rapid change without fixing other consumers, but I'm definitely +1 on the quick help from Hans on it. The TCP patch will need some closer review by people who have recently worked on the TCP stack and locking. I'll try to get the Verisign developers looped in as they touched this stuff recently. I do think we could do with a debugging print for now to catch situations which need migrating. The callout API doesn't tell you that it did or didn't migrate an event to another CPU and it could make for some performance unpredictability. -a _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
