> 23.09.2014 14:55, Chris.Pringle@xxxxxxxxxxxxxxx пишет: > > > > I've attached the patch for reference. > > ported you fixes to 3.14.19 + patch-3.14.12-rt9.patch.gz > Intel Celeron G1620, while working :) > > http://i67.fastpic.ru/big/2014/0923/39/df38663bd2414afe064c1978ad7b3d39.jpg Thanks for trying. Unfortunately, I don't think this is a workable fix as I'm pretty convinced that changing the spin lock type is not the right thing to do for RT.. I have backported all fixes in aio.c and workqueue.c from v3.14 (rt9) to v3.12 and have seen some improvement in one of my test cases (although I have suspicions it's just masking the problem), however the other is still failing as previously posted. In v3.0 of the kernel, the aio stuff never used the new percpu ref counting so I think this is a new problem introduced/revealed by that. I guess the question is, do we expect it to be safe to call schedule_work() from atomic context (as Ben LaHaise suggested)? If the answer is yes, then there is a bug in the workqueues, if the answer is no, then the bug is in fs/aio.c in the way it cleans up reqs via the percpu refcounting (which eventually calls schedule_work()). DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. ЪТХ╨{.nг+┴╥÷╝┴╜├+%┼кЪ╠Ищ╤╔┼wЪ╨{.nг+┴╥╔┼{╠Ч╩Ъ╨г╚ЁЬ╖╤⌡║э╗}╘·╡ф═zз&j:+v┴╗ЧЬ ╞Ы ╝w╔Ч┼Ю2┼ч≥╗Х╜з&╒)ъ║╚a╤зЪЪШЮz©Дz╧ч≈З+┐Ы ▌┼щ╒jЪ┼wХЧf
