tech-kern archive

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

Re: Ubiquitous ucas(9)




> On Mar 31, 2019, at 3:12 PM, Mindaugas Rasiukevicius <rmind%netbsd.org@localhost> wrote:
> 
> A few comments:
> 
> - Kernel preemption is implicitly disabled at IPL_HIGH, so you do not need
> to do it explicitly.

Ah, of course.  Makes sense.

> - Consider re-using the cpu_lock instead of adding ucas_critical_mutex.

Done.

> - Also, consider using kcpuset_copy(&ucas_kcpuset, kcpuset_attached),
> plus clearing the current CPU; ucas_kcpuset can be global and it would
> be already protected by cpu_lock.  Alternatively, you can add a third
> parameter to ipi_trigger_multi(), e.g. "bool exclude_curcpu", as it is
> arguably a common case.  Then you would just use kcpuset_attached.

I added a ipi_trigger_broadcast() that takes a bool "skip_self" argument.  (I added the same to ipi_broadcast() for symmetry.)

I also found what I think is a bug in ipi_trigger_multi() -- in the "send to self" case, it was calling the ipi_cpu_handler(), but never setting the target IPI as pending, at least that I could see.  I fixed this, even though I wanted to skip_self :-)

> - You can get away with one counter (eliminating ucas_critical_owning_cpu)
> if you set it to ncpu (well, kcpuset_countset(kcpuset_attached) - 1) and
> decrement.  Note: once it reaches zero, you can use -1 in order to release
> the waiters on other CPU.
> 
> - The counter must be volatile or accessed through a volatile cast.

Cool, I will tidy those up.

Thanks for the feedback.

-- thorpej



Home | Main Index | Thread Index | Old Index