[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56CBEA4A.8070001@amd.com>
Date: Tue, 23 Feb 2016 12:12:42 +0700
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>
To: Peter Zijlstra <peterz@...radead.org>
CC: <joro@...tes.org>, <bp@...en8.de>, <mingo@...hat.com>,
<acme@...nel.org>, <andihartmann@...enet.de>,
<linux-kernel@...r.kernel.org>, <iommu@...ts.linux-foundation.org>
Subject: Re: [PATCH V4 5/6] perf/amd/iommu: Enable support for multiple IOMMUs
Hi
On 02/22/2016 09:07 PM, Peter Zijlstra wrote:
> On Mon, Feb 22, 2016 at 03:00:31PM +0700, Suravee Suthikulpanit wrote:
>>> So I really don't have time to review new muck while I'm hunting perf
>>> core fail, but Boris made me look at this.
>>>
>>> This is crazy, if you have multiple IOMMUs then create an event per
>>> IOMMU, do _NOT_ fold them all into a single event.
>>
>> These are system-wide events, which are programmed on every IOMMU the same
>> way. I am not sure what you meant by creating an event per IOMMU. Do you
>> mean I should create internal per-IOMMU struct perf_event for each event?
>
> No, I meant to expose each IOMMU individually to userspace, as a
> separate device.
>
> Is there never a case to profile just one of the IOMMUs ?
>
I see. That's definitely doable and simpler to implement.
I was not sure if making users specify the IOMMU instance (e.g.
amd_iommu_0/<ev name> , amd_iommu_1/<ev_name>, ....) would be too
tedious. However, this would actually give users better control of the
performance events, which is a good trade-off. I think it is acceptable.
I'll make the change and send this out in V5.
Thanks,
Suravee
Powered by blists - more mailing lists