From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Wenjia Zhang <wenjia@linux.ibm.com>
Cc: Gerd Bayer <gbayer@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
iommu@lists.linux.dev, linux-s390@vger.kernel.org,
borntraeger@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
svens@linux.ibm.com, linux-kernel@vger.kernel.org,
Julian Ruess <julianr@linux.ibm.com>
Subject: Re: [PATCH v4 4/7] s390/pci: Use dma-iommu layer
Date: Thu, 19 Jan 2023 11:12:11 -0500 [thread overview]
Message-ID: <5d0b26b1-ffc5-94dd-ced2-52cfef3842a4@linux.ibm.com> (raw)
In-Reply-To: <0ce7d96b8447a293b147976e5993cb053feb9c52.camel@linux.ibm.com>
On 1/19/23 11:04 AM, Niklas Schnelle wrote:
> On Thu, 2023-01-19 at 10:59 -0500, Matthew Rosato wrote:
>> On 1/19/23 6:03 AM, Niklas Schnelle wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> static char *pci_sw_names[] = {
>>>>>>>>>>>>>>>>>>> - "Allocated pages",
>>>>>>>>>>>>>>>>>>> +/* TODO "Allocated pages", */
>>>>>>>>>>>
>>>>>>>>>>> ? Forgot to finish this?
>>>
>>> Definitely forgot to remove the TODO. I think my latest plan was to
>>> just remove this counter. With the DMA API conversion the
>>> dma_map_ops.alloc and dma_map_ops.free move to common code and I don't
>>> see how we could differentiate these from map/unmap on our side. I'm
>>> not sure how helpful this counter really is either. If you're
>>> interested in how many pages are mapped long term I think it makes more
>>> sense to look at the difference between mapped and unmapped pages. What
>>> do you think?
>>>>>>>>>>
>>
>> Sounds reasonable to me, but I also note that without this series, when viewing statistics for a device, mapped - unmapped != allocated. Maybe allocated pages was already broken, or is it taking into account something else that mapped - unmapped would not (maybe mapping the same page multiple times)?
>>
>>
>
> Allocated Pages only counts the memory allocated via dma_map_ops.alloc
> so it would not count long term mappings of memory the driver allocated
> differently and then mapped for long term use.
Oh, right, I see it now.
Seems to me then that mapped-unmapped is more indicative of the actual footprint anyway so in the absence of an obvious analogue I'm fine with just getting rid of it.
next prev parent reply other threads:[~2023-01-19 16:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-04 12:05 [PATCH v4 0/7] iommu/dma: s390 DMA API conversion and optimized IOTLB flushing Niklas Schnelle
2023-01-04 12:05 ` [PATCH v4 1/7] s390/ism: Set DMA coherent mask Niklas Schnelle
2023-01-17 15:09 ` Matthew Rosato
2023-01-04 12:05 ` [PATCH v4 2/7] iommu: Allow .iotlb_sync_map to fail and handle s390's -ENOMEM return Niklas Schnelle
2023-01-05 7:15 ` Baolu Lu
2023-01-17 15:10 ` Matthew Rosato
2023-01-19 11:31 ` Niklas Schnelle
2023-01-04 12:05 ` [PATCH v4 3/7] s390/pci: prepare is_passed_through() for dma-iommu Niklas Schnelle
2023-01-17 15:10 ` Matthew Rosato
2023-01-04 12:05 ` [PATCH v4 4/7] s390/pci: Use dma-iommu layer Niklas Schnelle
2023-01-17 15:09 ` Matthew Rosato
2023-01-19 11:03 ` Niklas Schnelle
2023-01-19 15:59 ` Matthew Rosato
2023-01-19 16:04 ` Niklas Schnelle
2023-01-19 16:12 ` Matthew Rosato [this message]
2023-01-19 16:33 ` Niklas Schnelle
2023-01-19 16:40 ` Matthew Rosato
2023-01-04 12:05 ` [PATCH v4 5/7] iommu/dma: Allow a single FQ in addition to per-CPU FQs Niklas Schnelle
2023-01-19 15:55 ` Niklas Schnelle
2023-01-19 16:16 ` Niklas Schnelle
2023-01-04 12:05 ` [PATCH v4 6/7] iommu/dma: Enable variable queue size and use larger single queue Niklas Schnelle
2023-01-04 12:05 ` [PATCH v4 7/7] iommu/dma: Add IOMMU op to choose lazy domain type Niklas Schnelle
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=5d0b26b1-ffc5-94dd-ced2-52cfef3842a4@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gbayer@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=julianr@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pmorel@linux.ibm.com \
--cc=robin.murphy@arm.com \
--cc=schnelle@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=wenjia@linux.ibm.com \
--cc=will@kernel.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