RFC: setting performance_cx_lowest=C2 in -HEAD to avoid lock contention on many-CPU boxes

K. Macy kmacy at freebsd.org
Sat Apr 25 17:18:52 UTC 2015


Perhaps use an arbitrary cutoff - say <= 8 cores - where the
cx_lowest=C3. This serialization isn't going to hurt on systems with
more modest core counts.

On Sat, Apr 25, 2015 at 9:31 AM, Adrian Chadd <adrian at freebsd.org> wrote:
> Hi!
>
> I've been doing some NUMA testing on large boxes and I've found that
> there's lock contention in the ACPI path. It's due to my change a
> while ago to start using sleep states above ACPI C1 by default. The
> ACPI C3 state involves a bunch of register fiddling in the ACPI sleep
> path that grabs a serialiser lock, and on an 80 thread box this is
> costly.
>
> I'd like to drop performance_cx_lowest to C2 in -HEAD. ACPI C2 state
> doesn't require the same register fiddling (to disable bus mastering,
> if I'm reading it right) and so it doesn't enter that particular
> serialised path. I've verified on Westmere-EX, Sandybridge, Ivybridge
> and Haswell boxes that ACPI C2 does let one drop down into a deeper
> CPU sleep state (C6 on each of these). I think is still a good default
> for both servers and desktops.
>
> If no-one has a problem with this then I'll do it after the weekend.
>
> Thanks!
>
>
>
> -adrian
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"


More information about the freebsd-arch mailing list