On Sun, Oct 05, 2014 at 12:16:46PM -0400, Tejun Heo wrote: > I think the thing which bothers me is that due to softirq we end up > bouncing the context twice. IRQ schedules threaded IRQ handler after > doing minimal amount of work. The threaded IRQ handler gets scheduled > and again it doesn't do much but basically just schedules block > softirq to actually run completions which is the heavier part. > Apparently this doesn't seem to hurt measureably but it's just weird. Hi Tejun, That is exactly the point I was concerned with when stated in one of changelogs "The downside of this change is introduction of a kernel thread". Splitting the service routine in two parts is a small change (in terms of code familiarity). Yet it right away provides benefits I could observe and justify (to myself at least). > Why are we bouncing the context twice? I *did* consider moving the threaded handler code to the softirq part. I just wanted to get updates in stages: to address hardware interrupts latency first and possibly threaded hander next. Getting done these two together would be too big change for me ;) > -- > tejun -- Regards, Alexander Gordeev agordeev@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
