On Wed, Oct 27 2021, Vineeth Vijayan <vneethv@xxxxxxxxxxxxx> wrote: > 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. Well, it's not exactly useless -- userspace gets notified that the device has bound to a driver, which was an information that was completely missing up to now for subchannels. The main issue is that the subchannel will get deregistered again (or has that been changed? Sorry, I've been out of the loop for too long...) > > 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 think the potentially problematic case is "lots of I/O subchannels with no valid device", and I think you can't get that under z/VM (which will not give you those subchannels in the first place), but only on LPAR. > > 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. I would probably also verify: - non-I/O subchannels (IIRC you can't have CHSC subchannels under z/VM, don't know about EADM, so that would need to be done on an LPAR as well) - interaction with driverctl (and maybe mdevctl) for vfio-ccw But I think I also may be a bit out of touch here :) > > > 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(-)
