> Il giorno 19 ott 2017, alle ore 08:46, Paolo Valente <paolo.valente@xxxxxxxxxx> ha scritto: > ... >>> >>> blkgs are, but the blkg_stat objects passed to the blkg_*stat_* >>> functions by bfq are not. In particular, these objects are contained >>> in bfq_group objects. I talked partial nonsense here. bfqg objects are in bfq, but a bfqg may die only after the corresponding blkg has died. So, if RCU protection guarantees that the blkg is alive when stat-update functions are invoked, then the RCU guarantees that bfqg is alive too. Still, I'm scratching my head over your claim that there is such a protection. The blkg obtained through a blkg_lookup, in a rcu_read section, is protected. But, outside that section, a pointer to that blkg is not guaranteed to be valid any longer. Stat-update functions seem safe in cfq and bfq, just because they are executed within locks that happen to be taken also before destroying the blkg. They are the request_queue lock for cfq and the scheduler lock for bfq. Thus, at least the request_queue lock apparently needs to be taken around stat-update functions in bfq, if they are moved outside the section protected by the scheduler lock. Thanks, Paolo >>> Anyway, as I wrote, the cost of using the >>> request_queue lock seems to be a loss of about 5% of the throughput. >>> So, I guess that replacing this lock with RCU protection would >>> probably reduce this loss to only 2% or 3%. I wonder whether such a >>> gain would be worth the additional conceptual complexity of RCU; at >>> least untill the major problem, i.e,, the apparently high cost of stat >>> update, is solved somehow. >>> >>> Thanks, >>> Paolo >>> >>>> Thanks. >>>> >>>> -- >>>> tejun >>> >>> <bfq-tracing-cgroup.svg> >> >
