On 5/26/2016 4:02 PM, Alexey Klimov wrote: > On Tue, May 17, 2016 at 12:39 AM, Prashanth Prakash <pprakash@xxxxxxxxxxxxxx> wrote: >> CPPC defined in section 8.4.7 of ACPI 6.1 specification suggests >> "To amortize the cost of PCC transactions, OSPM should read or write >> all PCC registers via a single read or write command when possible" >> This patch enables opportunistic batching of frequency transition >> requests whenever the request happen to overlap in time. >> >> Currently the access to pcc is serialized by a spin lock which does >> not scale well as we increase the number of cores in the system. This >> patch improves the scalability by allowing the differnt CPU cores to >> update PCC subspace in parallel and by batching requests which will >> reduce certain types of operation(checking command completion bit, >> ringing doorbell) by a significant margin. >> >> Profiling shows significant improvement in the time to service freq. >> transition request. Using a workload which includes multiple iteration >> of configure+make of vim (with -j24 option): >> Without batching requests(without this patch), >> 6 domains: Avg=20us/request; 24 domains: Avg=52us/request >> With batching requests(with this patch), >> 6 domains: Avg=16us/request; 24 domains: Avg=19us/request >> domain: An individual cpu or a set of related CPUs whose frequency can >> be scaled independently > With this approach sometimes you will send POSTCHANGE notifications about > frequency change for some random CPUs before actual request to change > frequency was sent (and received?) through PCC channel. > Depending on platform/firmware/configuration this time difference might be high. > > How vital or important is to have POSTCHANGE notification in correct time > order? Good catch. Yeah, we could end up notifying POSTCHANGE prior to ringing the doorbell. I haven't thought about this a lot and not sure if there are clients that rely on the accuracy of the notification. Anyways, I suppose we can make cppc_set_perf return a value to indicate if a request was delivered (i.e doorbell was rang) or batched (request updated, but doorbell will be rung by a different CPU). Using this return value cppc_cpufreq_set_target can notify all the pending CPUs at once or queue to be notified. Sounds reasonable? Also, if we think about CPPC, since we don't have a way to know exactly when platform did the frequency/voltage transition, I suppose POSTCHANGE will be a little out of order :) Thanks, Prashanth > Best regards, > Alexey. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
