Re: [RFC PATCH v2] Add rcu user eqs exception hooks for async page fault

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2012/11/29 Li Zhong <zhong@xxxxxxxxxxxxxxxxxx>:
> On Wed, 2012-11-28 at 13:55 +0100, Frederic Weisbecker wrote:
>> > With rcu_user_exit() at the beginning, now rcu_irq_enter() only protects
>> > the cpu idle eqs, but it's not good to call rcu_irq_exit() after the cpu
>> > halt and the page ready.
>>
>> Hmm, why is it not good?
>
> I think in this case, as cpu halts and waits for page ready, it is
> really in idle, and it's better for rcu to think it as rcu idle. But
> with rcu_irq_enter(), the rcu would not think this cpu as idle. And the
> rcu_irq_exit() is only called after this idle period to mark this cpu as
> rcu idle again.


Indeed. How about calling rcu_irq_exit() before native_safe_halt() and
rcu_irq_enter() right after?

>> > So I still want to remove it. And later if it shows that we really needs
>> > rcu somewhere in this code path, maybe we could use RCU_NONIDLE() to
>> > protect it. ( The suspicious RCU usage reported in commit
>> > c5e015d4949aa665 seems related to schedule(), which is not in the code
>> > path if we are in cpu idle eqs )
>>
>> Yes but if rcu_irq_*() calls are fine to be called there, and I
>> believe they are because exception_enter() exits the user mode, we
>> should start to protect there right now instead of waiting for a
>> potential future warning of illegal RCU use.
>
> I agree, but I think by only protecting the necessary code avoids
> marking the entire waiting period as rcu non idle.

If we use RCU_NONIDLE(), this assume we need to check all the code
there deeply for potential RCU uses and ensure it will never be
extended later to use RCU. We really don't scale enough for that.
There are too much subsystems involved there: waitqueue, spinlocks,
slab, per cpu, etc...

So I strongly suggest we use rcu_irq_*() APIs, and relax them around
native_safe_halt() like I suggested above. This seems to me the safest
solution.
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux