From: Vineeth Vijayan <vneethv@linux.ibm.com>
To: cohuck@redhat.com, linux-s390@vger.kernel.org
Cc: oberpar@linux.ibm.com, vneethv@linux.ibm.com
Subject: [RFC v2 0/1]s390/cio: remove uevent suppress from cio driver
Date: Wed, 27 Oct 2021 10:50:58 +0200 [thread overview]
Message-ID: <20211027085059.544736-1-vneethv@linux.ibm.com> (raw)
This is the follow-up for the old RFC which i have posted here couple of
months back. During the previous discussions on that RFC we concluded
that removing the uevent-suppress from the CIO layer is the cleaner way
of doing it and we should proceed. Reason for this RFC is, i want to
convince myself that, i am not doing something wrong. I would like to
bring up some of the tests i have done and the conclusion from those
tests.
The reason for introducing the delay in uevent generation was to avoid a
uevent storm from those subchannels which does not have a valid device
connected on this. I think for the new generation Z machines, this is
not inconsequential. The bigger worry was, how this change is going to
effect servers with lots of devices connected to them.
For example, with this change, we are introducing a new uevent, which
was previously suppressed. Below is the udevadm monitor report which
shows the uevent generated when we define a new dasd device.
$: vmcp def t3390 e002 1
DASD E002 DEFINED
KERNEL[53.083552] add /devices/css0/0.0.13af (css)
* KERNEL[53.083590] bind /devices/css0/0.0.13af (css)
KERNEL[53.086561] add /devices/css0/0.0.13af/0.0.e002 (ccw)
KERNEL[53.087136] bind /devices/css0/0.0.13af/0.0.e002 (ccw)
This new uvent on css (Which is highlighed with *), does not have a bigger
impact on the machines. But, they are useless for those subchannels without
a proper device associated with it.
We wanted to make sure that this new uevents are not giving bigger
impacts on customer machines which would accommodate many more devices on
an LPAR. One test to simulate this scenario was to define more than 5000
dasd devices on a zVM and check the boot and initialization delay with and
without this patch. This does not show any impact on the zVM with high
number of devices.
I dont see any specific impact on this patch as of now. But, if you
think there is some more testing which are required before we push this
patch, please do let me know.
Vineeth Vijayan (1):
s390/cio: remove uevent suppress from css driver
drivers/s390/cio/chsc_sch.c | 5 -----
drivers/s390/cio/css.c | 19 -------------------
drivers/s390/cio/device.c | 18 ------------------
drivers/s390/cio/eadm_sch.c | 5 -----
drivers/s390/cio/vfio_ccw_drv.c | 5 -----
5 files changed, 52 deletions(-)
--
2.25.1
next reply other threads:[~2021-10-27 8:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 8:50 Vineeth Vijayan [this message]
2021-10-27 8:50 ` [PATCH] s390/cio: remove uevent suppress from cio driver Vineeth Vijayan
2021-11-02 15:42 ` Cornelia Huck
2021-11-02 15:31 ` [RFC v2 0/1]s390/cio: " Cornelia Huck
2021-11-03 13:17 ` Vineeth Vijayan
2021-11-03 15:41 ` Cornelia Huck
2021-11-05 14:11 ` Vineeth Vijayan
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=20211027085059.544736-1-vneethv@linux.ibm.com \
--to=vneethv@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=linux-s390@vger.kernel.org \
--cc=oberpar@linux.ibm.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