Note that there are some explanatory texts on larger screens.

plurals
  1. POHow can I prevent a task to be moved from a CPU to another?
    text
    copied! <p>I am currently building a Kernel module and I want to face SMP issues in a quite-optimal way.</p> <p>Currently, I have a set of objects and each one is bound to a particular CPU. The following code illustrates this :</p> <pre class="lang-c prettyprint-override"><code>struct my_object { int a_field; }; struct my_object cpu_object[NR_CPUS]; /* * cpu_object[i] is "bound" to CPU number "i" ! */ </code></pre> <p>A simple call to <code>smp_processor_id()</code> will then give me the processor on which the current code is running. So if I have a function <code>foo</code> that does some work using the CPU-bound objects described above, it might look like :</p> <pre class="lang-c prettyprint-override"><code>void foo() { int cpu = smp_processor_id(); do_some_work_with(cpu_object[cpu]); } </code></pre> <p>The question is : How to guarantee that</p> <ol> <li>There is no CPU switch between <code>cpu</code> assignment and <code>do_some_work_with</code> ?</li> <li><code>do_some_work_with()</code> will only run on <code>cpu</code> ?</li> </ol> <p>At the time, the solution I think about is :</p> <ol> <li>Disable preemption using a spinlock</li> <li>Get the CPU with <code>smp_processor_id</code></li> <li>Set the processor affinity of the current task to make it stick with the current CPU</li> <li>Enable preemption again, releasing the lock</li> <li>Do the work <code>do_some_work_with()</code></li> <li>Reset the affinity to its previous state</li> </ol> <p>To me it is quite barbarian and I was wondering if there was smarter and lighter way to do it.</p> <p>Thanks in advance.</p> <hr> <p><strong>EDIT</strong> : As stated in the comments, I edit to explain why I feel I need such features. I have to perform on-the-fly encryption on a <em>filesystem</em> level.<br> To do so, I will use the Kernel built-in cryptographic support (<code>struct crypto_tfm</code> and friends). Here is the original issue...</p> <p>On multi-core machines, it is possible to perform multiple R/W operations at the same time. The common fs layer does it and does it well. But, here I come and mess things up :</p> <ul> <li>A <code>struct crypto_tfm</code>-like object is in charge for the ciphering operation</li> <li>A same transform object cannot be used at the same time since some parameters would be altered (private key and initialization vector) and screw all the process</li> <li>A naive solution as described below is completely out of the question due to the complex cipher allocation system built in crypto. <ol> <li>Allocate the <code>crypto_tfm</code> transformation</li> <li>Perform the ciphering operation</li> <li>Free the transformation object</li> </ol></li> <li>A classic scheme where only one transform is available prevents multiple concurrent R/W operations since one task would have to wait for another to release the lock held to protect the transform object.</li> </ul> <p>For these reasons, I need to deal with multiple transformation objects. I must find an efficient scheme that allows concurrent R/W. I feel my "Y" here is "the solution that is simple, neat ... and wrong". Any suggestion would be much appreciated.</p> <p><em>Note</em> : If I use a solution like the one I gave in the original question, I would limit it to very short sections to avoid heavy impact on CPU load balancing.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload