Re: Tentative proposal: TS mutexes should be queues not OS mutexes

On Wed, Oct 2, 2019 at 3:19 PM Kees Spoelstra wrote: > I think we're all able to dig some ratholes with less code than 30 lines. > Him, I thought "rathole" implied unneeded complexity but it seems to be just a synonym for "bad". > > Alan, it's only my fault that I pushed for threadaffinity for

Re: Handling requests to an upstream that is unresponsive.

You need to talk to the L7R group at the summit. What does it do if no upstream is available? That's the actual issue my change would address. I do think we should either make this change, or simply remove support for handling dead upstrreams - the current implementation is worse than useless IMHO.

Re: Handling requests to an upstream that is unresponsive.

Yes, as a supplement for what Sudheer pointed out, on LI Traffic's roadmap, we're adopting dynamic-discovery (D2), a client-side load-balancing strategy that can gracefully solve the issue. If some origin servers are

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

I think we're all able to dig some ratholes with less code than 30 lines. Alan, it's only my fault that I pushed for threadaffinity for plugins after I saw how it was in core... Can't keep all the goodies for the core :) One thing to watch out for is in order execution of continuations, as I've m

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

On Wed, Oct 2, 2019 at 2:25 PM Leif Hedstrom wrote: > > > > On Oct 2, 2019, at 1:00 PM, Walt Karas > wrote: > > > > I feel like you overestimate me if you think I could create a rathole > with > > just 30 lines of pseudo-code. > > We have faith in you. > What's an example of a rathole I've alre

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

> On Oct 2, 2019, at 1:00 PM, Walt Karas > wrote: > > I feel like you overestimate me if you think I could create a rathole with > just 30 lines of pseudo-code. We have faith in you. > > We're making complex thread affinity changes, on top of an event execution > code that already seem com

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

I feel like you overestimate me if you think I could create a rathole with just 30 lines of pseudo-code. We're making complex thread affinity changes, on top of an event execution code that already seem complex. (I leave it to those with more rathole background to say if it should be so labeled.)

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

I've done some profiling before, using Intel's VTune, you can ask Jason for details. On Wed, Oct 2, 2019 at 1:32 PM Leif Hedstrom wrote: > > > > On Oct 2, 2019, at 11:23 AM, Walt Karas > wrote: > > > > What's the best tool for multi-threaded profiling on Linux? > > Probably the Intel tools. Pr

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

> On Oct 2, 2019, at 11:23 AM, Walt Karas > wrote: > > What's the best tool for multi-threaded profiling on Linux? Probably the Intel tools. Probably the “perf” toolchain works well, at least on modern linux, you could do perf lock etc. > > On Wed, Oct 2, 2019 at 10:14 AM Alan Carroll >

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

The thing with profiling is trying to cover all the important traffic mixes and plugin use (impossible because of proprietary plugins). It seems desirable to have a design that's robust even when Continuations block more than they ideally should. Having a single run queue per core and N worker ev

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

What's the best tool for multi-threaded profiling on Linux? On Wed, Oct 2, 2019 at 10:14 AM Alan Carroll wrote: > Correct, it doesn't mean no lock contention. The claim was it reduced the > lock contention to a level where it's not significant enough to warrant > additional preventative measures

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

Correct, it doesn't mean no lock contention. The claim was it reduced the lock contention to a level where it's not significant enough to warrant additional preventative measures. The data Dan got wasn't from code analysis, but from run time profiling. That was a while ago so if you'd like to perfo