[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD thread model: a few questions
Andrew Doran wrote:
Yes it's valid. Ideally you would take the lock first and then disable
preemption, especially if it's known that the lock could cause the caller to
spin-wait for some time. I realise that's not always possible or easy; it's
the ideal pattern.
You want to do complete CPU offline, right? I will describe it as 'pause'
because we already have an 'offline' :-)
Yes, exactly, a complete CPU shutdown. I did not look at the device
interrupts/event channels code yet, but I guess that they will be easier
to handle by masking them.
. For userspace threads that have
affinity or are part of a processor set any pause would need to be prevented
and an error returned.
For kernel activity and bound threads here is my suggestion:
- Offline the cpu when beginning pause (SPFC_OFFLINE).
- Scan the callout table on the target CPU and migrate all its callouts to a
CPU that will still be online+unpaused. Ensure that callouts will not be
migrated back onto the target CPU while it is _offline_. That could be as
simple as a check for the SPCF_OFFLINE flag. See kern_timeout.c.
- When starting the CPU back up, clear SPCF_PAUSELOOP with a unicast xcall.
Nice! I will take a close look at this.
Many many thanks for the help and guidance, Andrew.
Main Index |
Thread Index |