Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754064AbcDMVME (ORCPT ); Wed, 13 Apr 2016 17:12:04 -0400 Received: from devils.ext.ti.com ([198.47.26.153]:35406 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754019AbcDMVMB (ORCPT ); Wed, 13 Apr 2016 17:12:01 -0400 Subject: Re: [PATCH v4 6/7] mtd: nand: omap2: Fix high memory dma prefetch transfer To: Boris Brezillon References: <1457654203-20856-1-git-send-email-fcooper@ti.com> <1457654203-20856-7-git-send-email-fcooper@ti.com> <20160321160443.0a4165d1@bbrezillon> <570EA72C.7000806@ti.com> <20160413222451.704376b5@bbrezillon> CC: , , , , , , , , From: "Franklin S Cooper Jr." Message-ID: <570EB5EC.3000206@ti.com> Date: Wed, 13 Apr 2016 16:11:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160413222451.704376b5@bbrezillon> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2311 Lines: 66 On 04/13/2016 03:24 PM, Boris Brezillon wrote: > Hi Franklin, > > On Wed, 13 Apr 2016 15:08:12 -0500 > "Franklin S Cooper Jr." wrote: > >> >> >> On 03/21/2016 10:04 AM, Boris Brezillon wrote: >>> Hi Franklin, >>> >>> On Thu, 10 Mar 2016 17:56:42 -0600 >>> Franklin S Cooper Jr wrote: >>> >>>> Based on DMA documentation and testing using high memory buffer when >>>> doing dma transfers can lead to various issues including kernel >>>> panics. >>> >>> I guess it all comes from the vmalloced buffer case, which are not >>> guaranteed to be physically contiguous (one of the DMA requirement, >>> unless you have an iommu). >>> >>>> >>>> To workaround this simply use cpu copy. The amount of high memory >>>> buffers used are very uncommon so no noticeable performance hit should >>>> be seen. >>> >>> Hm, that's not necessarily true. UBI and UBIFS allocate their buffers >>> using vmalloc (vmalloced buffers fall in the high_memory region), and >>> those are likely to be dis-contiguous if you have NANDs with pages > 4k. >>> >>> I recently posted patches to ease sg_table creation from any kind of >>> virtual address [1][2]. Can you try them and let me know if it fixes >>> your problem? >> >> It looks like you won't be going forward with your patchset based on >> this thread [1]. > > Nope. According to Russell it's unsafe to do that. > >> I can probably reword the patch description to avoid >> implying that it is uncommon to run into high mem buffers. Also DMA with >> NAND prefetch suffers from a reduction of performance compared to CPU >> polling with prefetch. This is largely due to the significant over head >> required to read such a small amount of data at a time. The >> optimizations I've worked on all revolved around reducing the cycles >> spent before executing the DMA request. Trying to make a high memory >> buffer able to be used by the DMA adds significant amount of cycles and >> your better off just using the cpu for performance reasons. > > Okay. > One comment though, why not using virt_addr_valid() instead of > addr >= high_memory here? I had no reason other than simply using the approach used in the driver already. Virt_addr_valid looks like it will work so I'll make the switch after testing it. > > Best Regards, > > Boris > >