From: Greg KH <gregkh@linuxfoundation.org>
To: kys@microsoft.com
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
olaf@aepfle.de, apw@canonical.com, vkuznets@redhat.com,
jasowang@redhat.com, leann.ogasawara@canonical.com,
marcelo.cerri@canonical.com, sthemmin@microsoft.com,
Dexuan Cui <decui@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>
Subject: Re: [PATCH 2/5] vmbus: suppress uevents for hv_sock devices
Date: Sun, 10 Sep 2017 10:09:44 +0200 [thread overview]
Message-ID: <20170910080944.GB3573@kroah.com> (raw)
In-Reply-To: <20170910060849.31898-2-kys@exchange.microsoft.com>
On Sat, Sep 09, 2017 at 11:08:46PM -0700, kys@exchange.microsoft.com wrote:
> From: Dexuan Cui <decui@microsoft.com>
>
> hv_sock driver is automatically loaded when an application creates an
> AF_VSOCK socket, so we don't really need to trigger uevents to the user
> space udevd.
>
> And hv_sock devices can appear and disappear frequency, e.g. 100 per
> second, so triggering the udevents can cause a high cpu utilization of
> udevd, e.g. 30% on a 2-cpu virtual machine. So let's suppress the
> uevents to avoid this.
100 per second for a struct device? That's crazy, and the uevent is the
least of your worries. Please fix that, as it's not the correct way to
use the driver model at all.
And really, why is uevent taking all that much cpu time anyway? It
_should_ be pretty fast, unless your distro is doing crazy things with
it...
sorry, am not going to take this patch.
greg k-h
next prev parent reply other threads:[~2017-09-10 9:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-10 5:53 [PATCH 0/5] Drivers: hv: Miscellaneous fixes kys
2017-09-10 6:08 ` [PATCH 1/5] vmbus: don't acquire the mutex in vmbus_hvsock_device_unregister() kys
2017-09-10 6:08 ` [PATCH 2/5] vmbus: suppress uevents for hv_sock devices kys
2017-09-10 8:09 ` Greg KH [this message]
2017-09-18 0:02 ` KY Srinivasan
2017-09-10 6:08 ` [PATCH 3/5] Drivers: hv: fcopy: restore correct transfer length kys
2017-09-10 6:08 ` [PATCH 4/5] vmbus: add per-channel sysfs info kys
2017-09-10 6:08 ` [PATCH 5/5] Drivers: hv: vmbus: Expose per-channel event counters kys
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=20170910080944.GB3573@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=apw@canonical.com \
--cc=decui@microsoft.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=jasowang@redhat.com \
--cc=kys@microsoft.com \
--cc=leann.ogasawara@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.cerri@canonical.com \
--cc=olaf@aepfle.de \
--cc=sthemmin@microsoft.com \
--cc=vkuznets@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome