On Mon, Oct 17, 2022 at 05:31:05PM +0200, Christoph Hellwig wrote: > On Mon, Oct 17, 2022 at 08:21:36AM -0700, Paul E. McKenney wrote: > > The main reason for having multiple srcu_struct structures is to > > prevent the readers from one from holding up the updaters from another. > > Except that by waiting for the multiple grace periods, you are losing > > that property anyway, correct? Or is this code waiting on only a small > > fraction of the srcu_struct structures associated with blk_queue? > > There are a few places that do this. SCSI and MMC could probably switch > to this scheme or at least and open coded version of it (if we move > to a per_tagsect srcu_struct open coding it might be a better idea > anyway). > > del_gendisk is one where we have to go one queue at a time, and > that might actually matter for a device removal. elevator_switch > is another one, there is a variant for it that works on the whole > tagset, but also those that don't. OK, thank you for the info! Then the big question is "how long do the SRCU readers run?" If all of the readers ran for exactly the same duration, there would be little point in having more than one srcu_struct. If the kernel knew up front how long the SRCU readers for a given entry would run, it could provide an srcu_struct structure for each duration. For a (fanciful) example, you could have one srcu_struct structure for SSDs, another for rotating rust, a third for LAN-attached storage, and a fourth for WAN-attached storage. Maybe a fifth for lunar-based storage. If it is impossible to know up front which entry has what SRCU read-side latency characteristics, then the current approach of just giving each entry its own srcu_struct structure is not at all a bad plan. Does that help, or am I off in the weeds here? Thanx, Paul
