> Il giorno 21 ott 2017, alle ore 18:13, Tejun Heo <tj@xxxxxxxxxx> ha scritto: > > Hello, Paolo. > > On Thu, Oct 19, 2017 at 08:50:17AM +0200, Paolo Valente wrote: >> 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 > > blkg's destruction is rcu delayed. If you have access to a blkg under > rcu, it won't get freed until the rcu read lock is released. > >> 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. > > So, a blkg stays alive if the queue lock is held, or the cgroup and > request_queue stays alive, and won't be freed (different from being > alive) as long as RCU read lock is held. > Ok, then I have either to protect these stats-update functions with the queue lock, or to extend somehow rcu protection to the bfq groups referred by these functions. According to our tests with different processors, the gain of the latter solution is probably around 2 or 3% of IOPS boost, with respect to using just the queue lock. It would be a little gain, against the current rather high overhead of the functions to protect. And it would cost additional code complexity. So I'm oriented towards using just the queue lock. Thank you very much for helping me with these doubts, Paolo > Thanks. > > -- > tejun
