All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Alexander Monakov <amonakov@ispras.ru>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	David Coe <david.coe@live.co.uk>, Joerg Roedel <joro@8bytes.org>,
	"Tj (Elloe Linux)" <ml.linux@elloe.vision>
Subject: Re: [PATCH] iommu/amd: Fix event counter availability check
Date: Fri, 26 Feb 2021 22:44:08 +0100	[thread overview]
Message-ID: <4aba4c61-1878-3d4e-d52e-3ccac9715010@molgen.mpg.de> (raw)
In-Reply-To: <alpine.LNX.2.20.13.2006030935570.3181@monopod.intra.ispras.ru>

[cc: +suravee, +jörg]

Dear Alex, dear Shuah, dear Suravee, dear Jörg,


Am 03.06.20 um 08:54 schrieb Alexander Monakov:
> On Tue, 2 Jun 2020, Shuah Khan wrote:
> 
>> I changed the logic to read config to get max banks and counters
>> before checking if counters are writable and tried writing to all.
>> The result is the same and all of them aren't writable. However,
>> when disable the writable check and assume they are, I can run
> [snip]
> 
> This is similar to what I did. I also noticed that counters can
> be successfully used with perf if the initial check is ignored.
> I was considering sending a patch to remove the check and adjust
> the event counting logic to use counters as read-only, but after
> a bit more investigation I've noticed how late pci_enable_device
> is done, and came up with this patch. It's a path of less resistance:
> I'd expect maintainers to be more averse to removing the check
> rather than fixing it so it works as intended (even though I think
> the check should not be there in the first place).
> 
> However:
> 
> The ability to modify the counters is needed only for sampling the
> events (getting an interrupt when a counter overflows). There's no
> code to do that for these AMD IOMMU counters. A solution I would
> prefer is to not write to those counters at all. It would simplify or
> even remove a bunch of code. I can submit a corresponding patch if
> there's general agreement this path is ok.
> 
> What do you think?

I like this idea. Suravee, Jörg, what do you think?

Commit 6778ff5b21b (iommu/amd: Fix performance counter initialization) 
delays the boot up to 100 ms, which is over 20 % on fast systems, and 
also just a workaround, and does not seem to work always. The delay is 
also not mentioned in the commit message.


Kind regards,

Paul


[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6778ff5b21bd8e78c8bd547fd66437cf2657fd9b

WARNING: multiple messages have this Message-ID (diff)
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Alexander Monakov <amonakov@ispras.ru>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: David Coe <david.coe@live.co.uk>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	"Tj \(Elloe Linux\)" <ml.linux@elloe.vision>
Subject: Re: [PATCH] iommu/amd: Fix event counter availability check
Date: Fri, 26 Feb 2021 22:44:08 +0100	[thread overview]
Message-ID: <4aba4c61-1878-3d4e-d52e-3ccac9715010@molgen.mpg.de> (raw)
In-Reply-To: <alpine.LNX.2.20.13.2006030935570.3181@monopod.intra.ispras.ru>

[cc: +suravee, +jörg]

Dear Alex, dear Shuah, dear Suravee, dear Jörg,


Am 03.06.20 um 08:54 schrieb Alexander Monakov:
> On Tue, 2 Jun 2020, Shuah Khan wrote:
> 
>> I changed the logic to read config to get max banks and counters
>> before checking if counters are writable and tried writing to all.
>> The result is the same and all of them aren't writable. However,
>> when disable the writable check and assume they are, I can run
> [snip]
> 
> This is similar to what I did. I also noticed that counters can
> be successfully used with perf if the initial check is ignored.
> I was considering sending a patch to remove the check and adjust
> the event counting logic to use counters as read-only, but after
> a bit more investigation I've noticed how late pci_enable_device
> is done, and came up with this patch. It's a path of less resistance:
> I'd expect maintainers to be more averse to removing the check
> rather than fixing it so it works as intended (even though I think
> the check should not be there in the first place).
> 
> However:
> 
> The ability to modify the counters is needed only for sampling the
> events (getting an interrupt when a counter overflows). There's no
> code to do that for these AMD IOMMU counters. A solution I would
> prefer is to not write to those counters at all. It would simplify or
> even remove a bunch of code. I can submit a corresponding patch if
> there's general agreement this path is ok.
> 
> What do you think?

I like this idea. Suravee, Jörg, what do you think?

Commit 6778ff5b21b (iommu/amd: Fix performance counter initialization) 
delays the boot up to 100 ms, which is over 20 % on fast systems, and 
also just a workaround, and does not seem to work always. The delay is 
also not mentioned in the commit message.


Kind regards,

Paul


[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6778ff5b21bd8e78c8bd547fd66437cf2657fd9b
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-02-26 21:44 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 20:07 [PATCH] iommu/amd: Fix event counter availability check Alexander Monakov
2020-05-29 20:07 ` Alexander Monakov
2020-05-31  7:22 ` Alexander Monakov
2020-05-31  7:22   ` Alexander Monakov
2020-06-01  2:48   ` Paul Menzel
2020-06-01  2:48     ` Paul Menzel
2021-02-21 13:44     ` Paul Menzel
2021-02-21 13:44       ` Paul Menzel
2020-06-02 23:51   ` Shuah Khan
2020-06-02 23:51     ` Shuah Khan
2020-06-03  6:54     ` Alexander Monakov
2020-06-03  6:54       ` Alexander Monakov
2021-02-26 21:44       ` Paul Menzel [this message]
2021-02-26 21:44         ` Paul Menzel
2021-02-26 21:55         ` Shuah Khan
2021-02-26 21:55           ` Shuah Khan
2020-06-01  7:37 ` Suravee Suthikulpanit
2020-06-01  7:37   ` Suravee Suthikulpanit
2020-06-01  9:01   ` Alexander Monakov
2020-06-01  9:01     ` Alexander Monakov
2020-06-01 15:10     ` Suravee Suthikulpanit
2020-06-01 15:10       ` Suravee Suthikulpanit
2020-06-01 16:09       ` Alexander Monakov
2020-06-01 16:09         ` Alexander Monakov
2020-06-15 20:48       ` Alexander Monakov
2020-06-15 20:48         ` Alexander Monakov
2020-06-16  9:35         ` Suravee Suthikulpanit
2020-06-16  9:35           ` Suravee Suthikulpanit
2020-06-30 19:22           ` Alexander Monakov
2020-06-30 19:22             ` Alexander Monakov
2020-09-17 17:55           ` Alexander Monakov
2020-09-17 17:55             ` Alexander Monakov
2021-02-21 13:49             ` Paul Menzel
2021-02-21 13:49               ` Paul Menzel
2021-02-22 17:59               ` Suravee Suthikulpanit
2021-02-22 17:59                 ` Suravee Suthikulpanit
2021-02-24 20:35                 ` Paul Menzel
2021-02-24 20:35                   ` Paul Menzel

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=4aba4c61-1878-3d4e-d52e-3ccac9715010@molgen.mpg.de \
    --to=pmenzel@molgen.mpg.de \
    --cc=amonakov@ispras.ru \
    --cc=david.coe@live.co.uk \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ml.linux@elloe.vision \
    --cc=skhan@linuxfoundation.org \
    --cc=suravee.suthikulpanit@amd.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.