On 01/10/2019 01:25 PM, James Morse wrote: > Hi Longman, Zhenzhong, > > On 10/01/2019 14:43, Waiman Long wrote: >> On 01/10/2019 03:02 AM, Zhenzhong Duan wrote: >>> There is a question confused me for days. Appreciate an answer. >>> >>> In below code, the comment says we never have more than 4 nested >>> contexts. >>> >>> What happen if debug and mce exceptions nest with the four, or we >>> ensure it never happen? >>> >>> >>> /* >>> * Per-CPU queue node structures; we can never have more than 4 nested >>> * contexts: task, softirq, hardirq, nmi. >>> * >>> * Exactly fits one 64-byte cacheline on a 64-bit architecture. >>> * >>> * PV doubles the storage and uses the second cacheline for PV state. >>> */ >>> static DEFINE_PER_CPU_ALIGNED(struct qnode, qnodes[MAX_NODES]); >> Yes, both debug and mce exceptions are some kind of NMIs. So >> theoretically, it is possible to have more than four. Are you aware of >> any debug and MCE exception handlers that need to take a spinlock for >> synchronization? > On arm64 if all the RAS and psuedo-NMI patches land, our worst-case > interleaving > jumps to at least 7. The culprit is APEI using spinlocks to protect fixmap > slots. > > I have an RFC to bump the number of node bits from 2 to 3, but as this is APEI > four times, it may be preferable to make it use something other than > spinlocks. > > > The worst-case order is below. Each one masks those before it: > 1. process context > 2. soft-irq > 3. hard-irq > 4. psuedo-nmi [0] > - using the irqchip priorities to configure some IRQs as NMI. > 5. SError [1] > - a bit like an asynchronous MCE. ACPI allows this to convey CPER records, > requiring an APEI call. > 6&7. SDEI [2] > - a firmware triggered software interrupt, only its two of them, either > of > which could convey CPER records. > 8. Synchronous external abort
Nested spinlocks isn't a problem as long as no more than 4 of them are contended. Adding one more bit for node will halving the number of CPUs supported without going to the slower version with a single pending bit. Cheers, Longman
