Hi Stephen,
> -----Original Message----- > From: Stephen Hemminger <[email protected]> > Sent: Monday, July 1, 2019 4:30 AM > To: Gavin Hu (Arm Technology China) <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; Honnappa Nagarahalli > <[email protected]>; nd <[email protected]> > Subject: Re: [dpdk-dev] [RFC 0/5] use WFE for locks and ring on aarch64 > > On Mon, 1 Jul 2019 00:21:11 +0800 > Gavin Hu <[email protected]> wrote: > > > DPDK has multiple use cases where the core repeatedly polls a location in > > memory. This polling results in many cache and memory transactions. > > > > Arm architecture provides WFE (Wait For Event) instruction, which allows > > the cpu core to enter a low power state until woken up by the update to the > > memory location being polled. Thus reducing the cache and memory > > transactions. > > > > x86 has the PAUSE hint instruction to reduce such overhead. > > > > The rte_wait_until_equal_xxx APIs abstract the functionality of 'polling > > for a memory location to become equal to a given value'. > > > > For non-Arm platforms, these APIs are just wrappers around do-while loop > > with rte_pause, so there are no performance differences. > > > > For Arm platforms, use of WFE can be configured using > CONFIG_RTE_USE_WFE > > option. It is disabled by default. > > > > Currently, use of WFE is supported only for aarch64 platforms. armv7 > > platforms do support the WFE instruction, but they require explicit wake up > > events(sev) and are less performannt. > > > > Testing shows that, performance varies across different platforms, with > > some showing degradation. > > > > CONFIG_RTE_USE_WFE should be enabled depending on the performance > on the > > target platforms. > > How does this work if process is preempted? WFE won't prevent pre-emption from the kernel as that is down to a timer/re-scheduling interrupt. Software using the WFE mechanism must tolerate spurious wake-up events, including timer/re-scheduling interrupts, so a re-check of the condition upon exit of WFE is needed to be in place(this is already included in the patch)
