From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752603AbcHHNih (ORCPT ); Mon, 8 Aug 2016 09:38:37 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:65515 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752161AbcHHNic (ORCPT ); Mon, 8 Aug 2016 09:38:32 -0400 X-IBM-Helo: d24dlp01.br.ibm.com X-IBM-MailFrom: mauricfo@linux.vnet.ibm.com X-IBM-RcptTo: linux-doc@vger.kernel.org;linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO_WARN attribute To: Andrew Morton References: <1470092390-25451-1-git-send-email-mauricfo@linux.vnet.ibm.com> <20160804150145.fb5690e9a873121db1dfa0b1@linux-foundation.org> <57A3DB17.3060603@linux.vnet.ibm.com> <20160804180501.f80c9b919341c486e2a95894@linux-foundation.org> <57A487CC.3040205@linux.vnet.ibm.com> <20160805100108.8f09fb7c1e63cd4ca06b16bd@linux-foundation.org> Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, corbet@lwn.net, rmk+kernel@arm.linux.org.uk, keith.busch@intel.com, axboe@fb.com, benh@kernel.crashing.org, mpe@ellerman.id.au, k.kozlowski@samsung.com From: Mauricio Faria de Oliveira Date: Mon, 8 Aug 2016 10:38:17 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160805100108.8f09fb7c1e63cd4ca06b16bd@linux-foundation.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16080813-0020-0000-0000-0000022C48D4 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16080813-0021-0000-0000-0000301442EB Message-Id: <57A88B49.7080406@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-08_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608080151 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/05/2016 02:01 PM, Andrew Morton wrote: > Bah. What about WARN__ON_ONCE()? Or much heavier ratelimiting? The problem w/ the WARN_ON_ONCE macro for this case is that it applies once per _function_ (because of its static variable), not per _device_. So, after the message happens for a particular device, it won't happen for any other devices. This would still conflict with the reasons the other patch (use dynamic debug) was rejected [1]. The other problem w/ WARN_ON_ONCE (even if it could be used per device) is that it masks/hides some events: if you reach it with requests that are OK to fail (i.e., retry), it will be silent for requests that are not OK to fail (e.g., the blk_integrity-related call on nvme) -- and it could be helpful for debugging. I believe that ratelimiting would fall into the same category as above (masks events since it hits the threshold with the OK-to-fail requests, and then misses the not-OK-to-fail requests). The other problem with ratelimiting would be, in case of continuously working on high loads with the devices (e.g., nvme drive) - which is acceptable - the messages would still eventually be printed, and since it will happen every time the threshold is OK to print it again, it's only a repetition with a greater period. ... the difficult point with the problem this patch addresses is not to be heavy handed; it's interesting to find some balance to still reach the message when it might be useful, and provide some form of control to the device driver (for when it knows it is OK for requests to fail). Given that the driver can have multiple callsites (with different or no failure handling), unfortunately I found it hard to make this arch-specific (but that is what I really aimed for first). If you see other approaches that could help with it, I'd be happy to write something simpler/more discreet. Thanks for the suggestions and discussions. [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-June/144196.html -- Mauricio Faria de Oliveira IBM Linux Technology Center