Re: [Question] PM-QoS: PM_QOS_CPU_DMA_LATENCY == interrupt latency?

From: Ming Lei
Date: Tue Oct 11 2011 - 05:36:41 EST


Hi,

On Tue, Oct 11, 2011 at 1:32 PM, Shaohua Li <shli@xxxxxxxxxx> wrote:
> 2011/10/11 Ming Lei <tom.leiming@xxxxxxxxx>:
>> Hi,
>>
>> On Tue, Oct 11, 2011 at 10:26 AM, Shaohua Li <shli@xxxxxxxxxx> wrote:
>>> 2011/10/11 Ming Lei <tom.leiming@xxxxxxxxx>:
>>>> Hi,
>>>>
>>>> On Tue, Oct 11, 2011 at 9:49 AM, Shaohua Li <shli@xxxxxxxxxx> wrote:
>>>>
>>>>> As Alan explained, PM_QOS_CPU_DMA_LATENCY is for dma snooping. For example,
>>>>> in x86, cpu snoop dma. when cpu is in idle state, cpu need snoop
>>>>> device dma activity, there
>>>>> is latency involved for idle state.
>>>>>
>>>>
>>>> I see, thanks for your clarification.
>>>>
>>>> I also have two further questions about it:
>>>>
>>>> - Except for dma snooping purpose, are there any other cases in which
>>>> PM_QOS_CPU_DMA_LATENCY is required?
>>> it's the main motivation, IIRC, don't know other platforms
>>
>> If so, maybe all device drivers which support DMA transfer should
>> have used PM_QOS_CPU_DMA_LATENCY, but why only few drivers
>> did it?
> depends on your device. Say cpu takes 1s to snoop dma in idle state, so device
> dma will cost more than 1s. if your device can work with such latency, no
> problem then.
>

Sorry, I am still a bit confused.

As you said before, for x86, some deep cpu idle states may stop dma
snoop, so introduce PM_QOS_CPU_DMA_LATENCY to prevent cpuidle from
entering such kind of deep idle state if I/O dma is in progress. I
understand the cpu dma pm qos should always be applied before starting
any dma transfer, Otherwise, cpu local cache may not be updated after
dma is over when cpu is returned from the deep idle state.

If so, the latency is only related with the exit latency of cpu idle
state in which dma snoop is stopped, instead of being related with I/O
devices.

Please correct me if the above is wrong.


thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/