All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Zijiang Huang <huangzjsmile@gmail.com>, lukas@wunner.de
Cc: bhelgaas@google.com, flyingpeng@tencent.com,
	huangzjsmile@gmail.com, kerayhuang@tencent.com,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: Using lockless config space accessors based on
Date: Wed, 07 May 2025 16:00:06 +0200	[thread overview]
Message-ID: <877c2smsgp.ffs@tglx> (raw)
In-Reply-To: <20250507090407.2146324-1-kerayhuang@tencent.com>

On Wed, May 07 2025 at 17:04, Zijiang Huang wrote:
> I think it's safe to make this change for user-space accessors as well,
> since user-space only reads from proc files.

Again. See pci_cfg_access_lock()

>> Why is performance of the user space accessors important?
>> Perhaps because of vfio?
>
> During stability testing on large-scale machines (384+ CPUs), we always                                             > observed that heavy concurrent user-space access to PCI config space triggers 
> kernel softlockups.
>  
> Reproduction method: stress-ng --pci 384 

This is not really interesting as stress-ng is not a real world work
load.

What's the actual real world use case which uses those interfaces so
that the lock becomes an issue?

Thanks,

        tglx

  reply	other threads:[~2025-05-07 14:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07  7:30 [PATCH] PCI: Using lockless config space accessors based on Kconfig option Zijiang Huang
2025-05-07  7:53 ` Lukas Wunner
2025-05-07  9:04   ` [PATCH] PCI: Using lockless config space accessors based on Zijiang Huang
2025-05-07 14:00     ` Thomas Gleixner [this message]
2025-05-07  9:11   ` [PATCH] PCI: Using lockless config space accessors based on Kconfig option Thomas Gleixner

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=877c2smsgp.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=bhelgaas@google.com \
    --cc=flyingpeng@tencent.com \
    --cc=huangzjsmile@gmail.com \
    --cc=kerayhuang@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    /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.