On Tue, Mar 1, 2016 at 3:31 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Sun, Feb 28, 2016 at 03:26:21AM +0100, Rafael J. Wysocki wrote: > >> > > That said I'm unconvinced about the approach still. >> > > >> > > Having more RT threads in a system that already is under RT pressure >> > > seems like >> > > a recipe for trouble. Moreover, it's likely that those new RT threads >> > > will >> > > disturb the system's normal operation somehow even without the RT >> > > pressure and >> > > have you investigated that? >> > >> > Sorry I'm not sure what you mean by disturb normal operation. >> >> That would introduce a number of extra RT threads that would be woken up >> quite >> often and on a regular basis, so there would be some extra RT noise in the >> system, especially on systems with one CPU per cpufreq policy and many CPUs. >> >> That's not present ATM and surely need not be completely transparent. > > Having RT tasks should not be a problem. You can always set their > priority such that they do not interfere with an actual RT workload. > >> > Generally speaking, increasing the capacity of a heavily loaded system >> > seems to me to be something that should run urgently, so that the system >> > can potentially get itself out of trouble and meet the workload's needs. >> > >> > > Also having them per policy may be overkill and >> > > binding them to policy CPUs only is not necessary. >> > > >> > > Overall, it looks like a dynamic pool of threads that may run on every >> > > CPU >> > > might be a better approach, but that would almost duplicate the >> > > workqueues >> > > subsystem, so is it really worth it? >> > > >> > > And is the problem actually visible in practice? I have no record of >> > > any reports >> > > mentioning it, although theoretically it's been there forever, so had it >> > > been >> > > real, someone would have noticed it and complained about it IMO. >> > >> > While I don't have a test case drawn up to provide it seems like it'd be >> > easy to create one. More importantly the interactive governor in Android >> > uses this same kind of model, starting a frequency change thread and >> > making it RT. Android is particularly sensitive to latency in frequency >> > response. So that's likely one big reason why you're not hearing about >> > this issue - some folks have already worked around it. >> >> OK, so Android is the reason. :-) >> >> Fair enough. I still think that care is needed here, though. > > So I sort of see the point of having per-cpu RT kthread tasks to effect > the OPP change for CFS. And here I would indeed suggest just having a > task per cpu, moving tasks about is too complex and generates even more > noise. > > But the problem of having RT tasks is that you should run RT tasks at > max OPP. > > Now you can probably fudge things and not account these RT tasks to the > RT 'workload' since you know their characteristics etc.. But its going > to be ugly I suspect.
Good point.
