<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 31, 2014, at 12:22 PM, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org">bbb@mpi-sws.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>On 27 Feb 2014, at 09:11, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org">bbb@mpi-sws.org</a>> wrote:<br><br><blockquote type="cite"><br>On 25 Feb 2014, at 23:37, Glenn Elliott <<a href="mailto:gelliott@cs.unc.edu">gelliott@cs.unc.edu</a>> wrote:<br><br><blockquote type="cite">Arg! I used GFP_ATOMIC in all of my code, not realizing Linux’s proc_create_data() would call plain kmalloc(). Here are two possible solutions:<br>1) Use kworker to set up the proc files after successful activation.<br>2) Use kworker to perform plugin activation.<br><br>I have run into a similar problem in my GPUSync branch. Here, I need plugin deactivation to wait/join on interrupt handling threads that are signaled to exit/shutdown. In GPUSync, an echo to /proc/litmus/active_plugin triggers an event on kworker, which invokes the real activation routine. Problem solved. However, plugin activation becomes asynchronous. You have to wait for some epsilon after activating a plugin to know if it was successful. That’s not very nice. I don’t know how else to approach the problem though.<br><br>Back to my sched-domains patch, normally I would advocate solution #1, since plugin activation remains synchronous. However, since I’ve run into this problem before, I am willing to entertain solution #2. I think we can defend against race conditions by serializing all plugin activation/deactivations on the same worker thread (perhaps we set up a reserved kworker just for litmus).<br><br>Questions of the Litmus community: Does anyone have an opinion one way or the other? Has atomic plugin activation caused you problems in the past?<br></blockquote><br>Hi Glenn,<br><br>is there a way to avoid introducing kthreads for this? How about we call a “prepare_plugin()” callback from switch_sched_plugin() (<a href="https://github.com/LITMUS-RT/litmus-rt/blob/staging/litmus/litmus.c#L447">https://github.com/LITMUS-RT/litmus-rt/blob/staging/litmus/litmus.c#L447</a>) before executing in atomic mode?<br><br>Basically:<span class="Apple-converted-space"> </span><br><br>1) acquire switching mutex<br>2) check preconditions (plugin known, no RT tasks, etc.)<br>3) call prepare_plugin() on new plugin while sleeping is ok, abort if non-zero return value<br>4) call stop_machine(), recheck preconditions, etc., do the actual switch<br>5) call cleanup_plugin() on old plugin<br>6) release switching mutex<br><br>This would keep the switch synchronous, allow sleeping to take place as part of prepare_plugin(), and does not require kthreads. Anything I’ve overlooked?<br></blockquote><br><br>I've coded up a simple patch for this. It seems to work ok.<br><br><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://github.com/LITMUS-RT/litmus-rt/compare/staging...prop%2Fdomain-non-atomic-alloc">https://github.com/LITMUS-RT/litmus-rt/compare/staging...prop%2Fdomain-non-atomic-alloc</a><br><br>As byproduct, these patches introduce a new API for disabling plugin switches, which I need for some other project anyway.<br><br>Please let me know if I accidentally broke something with the patch. Otherwise, I'll merge it for the next release, which I intend to prepare soon.<br><br>Thanks,<br>Björn<br></div></blockquote></div><div><br></div><br><div>Looks good to me. I’m sorry that I wasn’t able to help out on this revision. Thank you for not leaving the patch behind.</div><div><br></div><div>-Glenn</div></body></html>