From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750839AbdBPFBy (ORCPT ); Thu, 16 Feb 2017 00:01:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50300 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750720AbdBPFBx (ORCPT ); Thu, 16 Feb 2017 00:01:53 -0500 Subject: Re: [PATCH] uio: add UIO_MEM_CUSTOM support To: Xiubo Li , Greg KH References: <1487133786-25545-1-git-send-email-lixiubo@cmss.chinamobile.com> <20170215171937.GA4705@kroah.com> Cc: mchristi@redhat.com, namei.unix@gmail.com, linux-kernel@vger.kernel.org From: Andy Grover Organization: Red Hat Message-ID: <01c3f279-813a-cc66-0760-b7c1fbfd6857@redhat.com> Date: Wed, 15 Feb 2017 21:01:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 16 Feb 2017 05:01:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/15/2017 05:34 PM, Xiubo Li wrote: >>> --- a/drivers/uio/uio.c >>> +++ b/drivers/uio/uio.c >>> @@ -708,6 +708,8 @@ static int uio_mmap(struct file *filep, struct >>> vm_area_struct *vma) >>> case UIO_MEM_LOGICAL: >>> case UIO_MEM_VIRTUAL: >>> return uio_mmap_logical(vma); >>> + case UIO_MEM_CUSTOM: >>> + return 0; >> How does this help? > For example, the TCMU will use the map area as ISCSI commands & data ring > buffer(uio0 --> map0). Currently the TCMU will using the fixed small > size map > area as the ring buffer, but this will be the bottleneck for high iops. > > Without knowing how large it is enough, so the new scheme will use the > fixed > small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring > buffer > area(about 1.5G). The following code is in uio_mmap() in uio.c: if (idev->info->mmap) { ret = idev->info->mmap(idev->info, vma); return ret; } switch (idev->info->mem[mi].memtype) { case UIO_MEM_PHYS: return uio_mmap_physical(vma); case UIO_MEM_LOGICAL: case UIO_MEM_VIRTUAL: return uio_mmap_logical(vma); default: return -EINVAL; } We already have the equivalent of a CUSTOM memtype because TCMU sets the info->mmap fn, overriding uio's default handling choices in favor of its own. HTH -- Regards -- Andy