Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 17 Jan 2018 19:09:39 -0800 | Subject | Re: [RFC PATCH 0/5] softirq: Per vector threading v2 |
| |
On Wed, Jan 17, 2018 at 6:55 PM, Frederic Weisbecker <frederic@kernel.org> wrote: >> I thought you were going to actally account for time, but I don't >> think you ended up doing that. > > I did in the first version but then I thought you suggested that count per > jiffy. I probably misunderstood :)
Oh, miscommunication.
I tried to suggest to do things purely by time (from an accounting standpoint), but then to also have some "minimum time" for each invocation, so that there effectively ends up being an invocation limit too.
Honestly, that's mainly because I worry about just how good the time-based approach might be (ie some hardware doesn't have a good high-frequency clock to read etc.
On x86-64, the TSC would be fairly natural as a clock, but we support architectures without anything like that, so time-based definitely has some issues.
But thinking about it more, I do end up liking my suggested "just keep a bitmap of softirqs that have been handled" thing, and kick the softirq to a thread if it ever seems to get into that "we already saw this one".
It might just work very naturally, and it sure as hell is simple and has no subtle interactions with the granularity of whatever random clock the architecture or platform has.
It should never trigger under any normal load, but I think it *should* trigger under the load that the networking people worry about. If you get a flood of UDP packets, and spend a lot of time in softirqs, I'm pretty sure you'd hit that case of seeing the same softirq re-raised fairly naturally and quickly.
Linus
| |