Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2563066imm; Mon, 24 Sep 2018 06:28:54 -0700 (PDT) X-Google-Smtp-Source: ACcGV62echLWdz1VkHMJSQ3MKJue6VcvTWeHGawG1jicI6kxP/+ZC+H/FhTpycDzpb67bzmix3yk X-Received: by 2002:a62:d884:: with SMTP id e126-v6mr10467799pfg.150.1537795734005; Mon, 24 Sep 2018 06:28:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537795733; cv=none; d=google.com; s=arc-20160816; b=NmbJWP9X7vQoCzIvv7Jo0fwrkY47uGfT1bTxajk1+ee7kV491s58ghCoqdqIhFA9v6 IDajxhXw/tLadacbLNy4dWDxPNxgpoX1Dfpmo0EiPEKRzSQKKXlEICS2f9Su9GQMmWdQ +9zHRXEOmkrqWXsWO+qG5a3GcN1nH4eGvurJKyERkx3J5pVeBgjilq4fsLZY1g+EC3BP Q8wK4Pvn1gEJ8h3cRZkCj2ktSIEkS/wRAw2PY0an7truxsl3RXELTNxziRwZW35UCB2K iM+SbR5JCK7FTsL9+PZsrOZa+Y9y+qfd9RxH5jIjjXdGRcIVBUDEp3BrI8Tq1b4qaQJm Rnaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=wuYw2GVkoLhkHmXBcwdVHFzCbEPp/79309asYHC9tqU=; b=WcPIUeHWZbFGw1JI9HtZnEDHkMXm1mmiZQ1LE5nmvUNo05s62zAXzUuUjf+2QZZfvw ivJ0RE/kjtTEhvW8i2KKkKUz/UlilCN07autoMut0KoBGLxASeelit82NZw17Auf3ZZt wni8K8Bf1TFdj46Z38RqzS/3b3mjnnQbmw0YpUy0+BUttnWIM9vww4WGiuliFoR3VHfa 5qHSkviAiCdTsS+By0L5CbK2wRPhZT+/a6P3ia0XdCr+sq+SEOcAf2dkMDreerj9Zvoj 8jCCBAbJRRSRPo+KEHG9xd+S/L1Nt1Ctu3GZ+RvMkTa0o8sQjFzpWUbL+6ArEYXDwoUi jRzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si35925490plu.65.2018.09.24.06.28.37; Mon, 24 Sep 2018 06:28:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731031AbeIXTal (ORCPT + 99 others); Mon, 24 Sep 2018 15:30:41 -0400 Received: from foss.arm.com ([217.140.101.70]:35760 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729307AbeIXTal (ORCPT ); Mon, 24 Sep 2018 15:30:41 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6199E18A; Mon, 24 Sep 2018 06:28:30 -0700 (PDT) Received: from [10.1.35.70] (e110479-lin.cambridge.arm.com [10.1.35.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9448D3F5BD; Mon, 24 Sep 2018 06:28:28 -0700 (PDT) Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback/common.h: use DIV_ROUND_UP instead of reimplementing its function To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: Jan Beulich , Jens Axboe , Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, xen-devel , zhong jiang References: <1536731100-56054-1-git-send-email-zhongjiang@huawei.com> <5B98CAE202000078001E79CC@prv1-mh.provo.novell.com> <20180912091350.6wuvt2jkvzg6wruo@mac.bytemobile.com> <20180912091639.oynlvdo6pghnqfvt@mac.bytemobile.com> <364bad2c-708e-6406-7b52-7bfef9d5dbe1@arm.com> <20180912102908.4ls7vts55n2zfkdz@mac.bytemobile.com> From: Julien Grall Message-ID: <58794c01-16f4-b124-46fe-cdcb386235de@arm.com> Date: Mon, 24 Sep 2018 14:28:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180912102908.4ls7vts55n2zfkdz@mac.bytemobile.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Roger, On 09/12/2018 11:29 AM, Roger Pau Monné wrote: > On Wed, Sep 12, 2018 at 10:48:42AM +0100, Julien Grall wrote: >> Hi, >> >> On 09/12/2018 10:16 AM, Roger Pau Monné wrote: >>> On Wed, Sep 12, 2018 at 11:13:50AM +0200, Roger Pau Monné wrote: >>>> Adding Julien how did the work to support XEN_PAGE_SIZE != PAGE_SIZE. >>>> >>>> On Wed, Sep 12, 2018 at 02:14:26AM -0600, Jan Beulich wrote: >>>>>>>> On 12.09.18 at 07:45, wrote: >>>>>> --- a/drivers/block/xen-blkback/common.h >>>>>> +++ b/drivers/block/xen-blkback/common.h >>>>>> @@ -65,7 +65,7 @@ >>>>>> (XEN_PAGES_PER_INDIRECT_FRAME / XEN_PAGES_PER_SEGMENT) >>>>>> #define MAX_INDIRECT_PAGES \ >>>>>> - ((MAX_INDIRECT_SEGMENTS + SEGS_PER_INDIRECT_FRAME - 1)/SEGS_PER_INDIRECT_FRAME) >>>>>> + DIV_ROUND_UP(MAX_INDIRECT_SEGMENTS, SEGS_PER_INDIRECT_FRAME) >>>>>> #define INDIRECT_PAGES(_segs) DIV_ROUND_UP(_segs, XEN_PAGES_PER_INDIRECT_FRAME) >>>>> >>>>> My first reaction was to suggest >>>>> >>>>> #define MAX_INDIRECT_PAGES INDIRECT_PAGES(MAX_INDIRECT_SEGMENTS) >>>>> >>>>> but that wouldn't match what's there currently (note the two different >>>>> divisors). I can't really decide whether that's just unfortunate naming >>>>> of the two macros, or an actual bug. >>>> >>>> I think there's indeed a bug here. >>>> >>>> AFAICT, MAX_INDIRECT_PAGES should use XEN_PAGES_PER_INDIRECT_FRAME and >>>> then it could be changed as Jan suggested. >> >> The problem is SEGS_PER_INDIRECT_FRAME has been miscalculated. So I think it >> would be fine to use XEN_PAGES_PER_INDIRECT_FRAME in MAX_INDIRECT_PAGES. >> >> However the naming for XEN_PAGES_PER_INDIRECT_FRAME is misnamed. We return >> number of a for segments per indirect frame. So I would rename to >> SEGS_PER_INDIRECT_FRAME. > > I don't think I agree with this last part, SEGS_PER_INDIRECT_FRAME > would have to take into account XEN_PAGES_PER_SEGMENT, and > XEN_PAGES_PER_INDIRECT_FRAME doesn't. > > XEN_PAGES_PER_INDIRECT_FRAME currently returns the number of grant > references per indirect page, but as I understand it a segment can use > more than one grant reference, if for example the guest page size is > 64KB. I am a bit confused. By segment, do you refer to the backend or frontend segment? In any case, it would be possible to remove SEGS_PER_INDIRECT_FRAME if we rework MAX_INDIRECT_PAGES(...). This should improve the readability as well. Cheers, -- Julien Grall