Messages in this thread | | | From | Yuyang Du <> | Date | Tue, 7 May 2019 10:21:58 +0800 | Subject | Re: [PATCH 19/28] locking/lockdep: Optimize irq usage check when marking lock usage bit |
| |
On Tue, 7 May 2019 at 09:47, Frederic Weisbecker <frederic@kernel.org> wrote: > > > But for usage checking, which vectors are does not really matter. So, > > > the current size of the arrays and bitmaps are good enough. Right? > > > > Frederic? My understanding was that he really was going to split the > > whole thing. The moment you allow masking individual soft vectors, you > > get per-vector dependency chains. > > Right, so in my patchset there is indeed individual soft vectors masked > so we indeed need per vector checks. For example a lock taken in HRTIMER > softirq shouldn't be a problem if it is concurrently taken while BLOCK softirq > is enabled. And for that we expand the usage_mask so that the 4 bits currently > used for general SOFTIRQ are now multiplied by NR_SOFTIRQ (10) because we need to > track the USED and ENABLED_IN bits for each of them. > > The end result is: > > 4 hard irq bits + 4 * 10 softirq bits + LOCK_USED bit = 45 bits. > > Not sure that answers the question as I'm a bit lost in the debate...
It was really I was lost: I didn't realize the enabling (or disabling) is going to be fine-grained as well until I read this changelog:
Disabling the softirqs is currently an all-or-nothing operation: either all softirqs are enabled or none of them. However we plan to introduce a per vector granularity of this ability to improve latency response and make each softirq vector interruptible by the others.
Sorry for the confusion I made :)
| |