From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen-blkback: don't store dev_bus_addr
Date: Tue, 19 Mar 2013 16:26:06 +0100 [thread overview]
Message-ID: <5148838E.8080808@citrix.com> (raw)
In-Reply-To: <20130319151000.GA8550@phenom.dumpdata.com>
On 19/03/13 16:10, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 19, 2013 at 02:55:56PM +0000, Jan Beulich wrote:
>>>>> On 19.03.13 at 15:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>> On Mon, Mar 18, 2013 at 05:49:32PM +0100, Roger Pau Monne wrote:
>>>> dev_bus_addr returned in the grant ref map operation is the mfn of the
>>>> passed page, there's no need to store it in the persistent grant
>>>> entry, since we can always get it provided that we have the page.
>>>>
>>>> This reduces the memory overhead of persistent grants in blkback.
>>>
>>> I took this patch, but I redid it a bit:
>>>
>>> commit 1d4cb410befdb8b373c6fad604b39e0200e0bee0
>>> Author: Roger Pau Monne <roger.pau@citrix.com>
>>> Date: Mon Mar 18 17:49:32 2013 +0100
>>>
>>> xen-blkback: don't store dev_bus_addr
>>>
>>> dev_bus_addr returned in the grant ref map operation is the mfn of the
>>> passed page, there's no need to store it in the persistent grant
>>> entry, since we can always get it provided that we have the page.
>>>
>>> This reduces the memory overhead of persistent grants in blkback.
>>>
>>> While at it, rename the 'seg[i].buf' to be 'seg[i].offset' as
>>> it makes much more sense - as we use that value in bio_add_page
>>> which as the fourth argument expects the offset.
>>>
>>> We hadn't used the physical address as part of this at all.
>>>
>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Cc: xen-devel@lists.xen.org
>>> [v1: s/buf/offset/]
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>
>>> diff --git a/drivers/block/xen-blkback/blkback.c
>>> b/drivers/block/xen-blkback/blkback.c
>>> index 2cf8381..061c202 100644
>>> --- a/drivers/block/xen-blkback/blkback.c
>>> +++ b/drivers/block/xen-blkback/blkback.c
>>> @@ -442,7 +442,7 @@ int xen_blkif_schedule(void *arg)
>>> }
>>>
>>> struct seg_buf {
>>> - unsigned long buf;
>>> + unsigned long offset;
>>
>> If you touch this anyway, why don't you reduce the type to
>> "unsigned int", halving the overall structure size?
>>
>> Even more, the field seems pointless to me altogether, since ...
>>
>>> unsigned int nsec;
>>> };
>>> /*
>>> @@ -621,30 +621,21 @@ static int xen_blkbk_map(struct blkif_request *req,
>>> * If this is a new persistent grant
>>> * save the handler
>>> */
>>> - persistent_gnts[i]->handle = map[j].handle;
>>> - persistent_gnts[i]->dev_bus_addr =
>>> - map[j++].dev_bus_addr;
>>> + persistent_gnts[i]->handle = map[j++].handle;
>>> }
>>> pending_handle(pending_req, i) =
>>> persistent_gnts[i]->handle;
>>>
>>> if (ret)
>>> continue;
>>> -
>>> - seg[i].buf = persistent_gnts[i]->dev_bus_addr |
>>> - (req->u.rw.seg[i].first_sect << 9);
>>> } else {
>>> - pending_handle(pending_req, i) = map[j].handle;
>>> + pending_handle(pending_req, i) = map[j++].handle;
>>> bitmap_set(pending_req->unmap_seg, i, 1);
>>>
>>> - if (ret) {
>>> - j++;
>>> + if (ret)
>>> continue;
>>> - }
>>> -
>>> - seg[i].buf = map[j++].dev_bus_addr |
>>> - (req->u.rw.seg[i].first_sect << 9);
>>> }
>>> + seg[i].offset = (req->u.rw.seg[i].first_sect << 9);
>>
>> ... this uses "i" as index on both sides, so ...
>>
>>> }
>>> return ret;
>>> }
>>> @@ -971,7 +962,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>> (bio_add_page(bio,
>>> pages[i],
>>> seg[i].nsec << 9,
>>> - seg[i].buf & ~PAGE_MASK) == 0)) {
>>> + seg[i].offset & ~PAGE_MASK) == 0)) {
>>
>> ... this one could as well use the original field.
>>
>> And the masking with ~PAGE_MASK is not pointless in any case.
>
> Good point. In which might as well make the 'struct seg_buf' be an
> simple array of unsigned int.
I didn't do this because later on (when using indirect segments) I need
a place to store the offset, since I don't have the indirect segment
pages mapped during the whole operation, but I guess I could change that.
>>
>> Jan
>>
>>>
>>> bio = bio_alloc(GFP_KERNEL, nseg-i);
>>> if (unlikely(bio == NULL))
>>> diff --git a/drivers/block/xen-blkback/common.h
>>> b/drivers/block/xen-blkback/common.h
>>> index da78346..60103e2 100644
>>> --- a/drivers/block/xen-blkback/common.h
>>> +++ b/drivers/block/xen-blkback/common.h
>>> @@ -187,7 +187,6 @@ struct persistent_gnt {
>>> struct page *page;
>>> grant_ref_t gnt;
>>> grant_handle_t handle;
>>> - uint64_t dev_bus_addr;
>>> struct rb_node node;
>>> };
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>
>>
next prev parent reply other threads:[~2013-03-19 15:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-18 16:49 [PATCH 0/5] xen-block: cleanup and fixes Roger Pau Monne
2013-03-18 16:49 ` [PATCH 1/5] xen-blkback: don't store dev_bus_addr Roger Pau Monne
2013-03-19 14:32 ` Konrad Rzeszutek Wilk
2013-03-19 14:55 ` [Xen-devel] " Jan Beulich
2013-03-19 15:10 ` Konrad Rzeszutek Wilk
2013-03-19 15:24 ` Jan Beulich
2013-03-19 15:26 ` Roger Pau Monné [this message]
2013-03-19 16:56 ` Konrad Rzeszutek Wilk
2013-03-18 16:49 ` [PATCH 2/5] xen-blkback: fix foreach_grant_safe to handle empty lists Roger Pau Monne
2013-03-18 16:49 ` [PATCH 3/5] xen-blkfront: switch from llist to list Roger Pau Monne
2013-03-19 12:51 ` Konrad Rzeszutek Wilk
2013-03-19 12:57 ` Roger Pau Monné
2013-03-19 14:31 ` Konrad Rzeszutek Wilk
2013-03-18 16:49 ` [PATCH 4/5] xen-blkfront: pre-allocate pages for requests Roger Pau Monne
2013-03-18 16:49 ` [PATCH 5/5] xen-blkfront: remove frame list from blk_shadow Roger Pau Monne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5148838E.8080808@citrix.com \
--to=roger.pau@citrix.com \
--cc=JBeulich@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox