linux-kernel - Re: [Question] PM-QoS: PM_QOS_CPU_DMA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACVXFVOqzr4S0-pFG_09Z47PugCWuDxLnGQX9AFm_QGEv3StgQ@mail.gmail.com>
Date:	Tue, 11 Oct 2011 17:36:39 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Shaohua Li <shli@...nel.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	mark gross <mgross@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux PM List <linux-pm@...r.kernel.org>
Subject: Re: [Question] PM-QoS: PM_QOS_CPU_DMA_LATENCY == interrupt latency?

Hi,

On Tue, Oct 11, 2011 at 1:32 PM, Shaohua Li <shli@...nel.org> wrote:
> 2011/10/11 Ming Lei <tom.leiming@...il.com>:
>> Hi,
>>
>> On Tue, Oct 11, 2011 at 10:26 AM, Shaohua Li <shli@...nel.org> wrote:
>>> 2011/10/11 Ming Lei <tom.leiming@...il.com>:
>>>> Hi,
>>>>
>>>> On Tue, Oct 11, 2011 at 9:49 AM, Shaohua Li <shli@...nel.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/