Date: Mon, 9 Jul 2012 08:38:05 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Cc: Andriy Gapon <avg@freebsd.org> Subject: Re: safe acpi_cpu_idle disabling Message-ID: <201207090838.05245.jhb@freebsd.org> In-Reply-To: <4FF96357.1030601@FreeBSD.org> References: <4FF96357.1030601@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, July 08, 2012 6:39:19 am Andriy Gapon wrote: > > I would like to propose the following patch for your review: > http://people.freebsd.org/~avg/acpi_cpu_disable_idle.diff > > The main purpose of this change is to provide safe interaction between > acpi_cpu_idle and dynamic C-state changes by disabling acpi_cpu_idle while > C-state data is updated. > > If my understanding is correct, currently there is no mutual protection between > acpi_cpu_idle code and acpi_cpu_cx_cst. The code more or less works by never > cleaning up old C-state data, so it is still accessible while the two functions > have incoherent views. There still could be problems when acpi_cpu_idle expects > C-state data at certain index to belong to one type while acpi_cpu_cx_cst > changes it to a different type. > > P.S. I think that cpu_disable_idle should be made per-CPU (go to acpi_cpu softc). I don't think you need the locking, I think all you need to add is the smp_rendezvous() call. The IPI mechanism has sufficient membar's already, and the smp_rendezvous() function itself will not return to the caller until all the CPUs can see the write to disable idling. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207090838.05245.jhb>