All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuyang Du <duyuyang@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: will.deacon@arm.com, Ingo Molnar <mingo@kernel.org>,
	Bart Van Assche <bvanassche@acm.org>,
	ming.lei@redhat.com, Frederic Weisbecker <frederic@kernel.org>,
	tglx@linutronix.de, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 19/28] locking/lockdep: Optimize irq usage check when marking lock usage bit
Date: Mon, 6 May 2019 11:42:05 +0800	[thread overview]
Message-ID: <CAHttsrZKx0cgs6t9ahxmV7ENp6QWG4H9N7KMvsgrucQ_rsqTJQ@mail.gmail.com> (raw)
In-Reply-To: <CAHttsrYfCdpNwQ81ppFQ9b_57tuLYOb=xi=CbRBysnB+LgjGGg@mail.gmail.com>

On Mon, 6 May 2019 at 11:05, Yuyang Du <duyuyang@gmail.com> wrote:
>
> On Tue, 30 Apr 2019 at 20:12, Peter Zijlstra <peterz@infradead.org> wrote:
> > > > IOW he's going to massively explode this storage.
> > >
> > > If I understand correctly, he is not going to.
> > >
> > > First of all, we can divide the whole usage thing into tracking and checking.
> > >
> > > Frederic's fine-grained soft vector state is applied to usage
> > > tracking, i.e., which specific vectors a lock is used or enabled.
> > >
> > > 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.
>
> It seems so. What I understand is: for IRQ usage, the difference is:
>
> Each lock has a new usage mask:
>
>         softirq10, ..., softirq1, hardirq
>
> where softirq1 | softirq2 | ... | softirq10 = softirq
>
> where softirq, exactly what was, virtually is used in the checking.
> This is mainly because, any irq vector has any usage, the lock has
> that usage, be it hard or soft.
>
> If that is right, hardirq can be split too (why not if softirq does
> :)). So, maybe a bitmap to do them all for tracking, and optionally
> maintain aggregate softirq and hardirq for checking as before.
> Regardless, may irq-safe reachability thing is not affected.
>
> And for the chain, which is mainly for caching does not really matter
> split or not (either way, the outcome will be the same?), because
> there will be a hash for a chain anyway, which is the same. Right?

Oh, another look at the patch, I was wrong, it can be very different
if consider: used in vector X vs. enabled on vector Y (which is ok),
when enablement can be so fine-grained as well, which is actually the
point of the patch, though no difference for now :(

  reply	other threads:[~2019-05-06  3:42 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 10:19 [PATCH 00/28] Optimize IRQ usage checks and other small bits Yuyang Du
2019-04-24 10:19 ` [PATCH 01/28] locking/lockdep: Change all print_*() return type to void Yuyang Du
2019-04-24 10:19 ` [PATCH 02/28] locking/lockdep: Add description and explanation in lockdep design doc Yuyang Du
2019-04-25 14:01   ` Peter Zijlstra
2019-04-26  5:41     ` Yuyang Du
2019-04-24 10:19 ` [PATCH 03/28] locking/lockdep: Adjust lock usage bit character checks Yuyang Du
2019-04-24 10:19 ` [PATCH 04/28] locking/lockdep: Remove useless conditional macro Yuyang Du
2019-04-24 10:19 ` [PATCH 05/28] locking/lockdep: Print the right depth for chain key colission Yuyang Du
2019-04-24 10:19 ` [PATCH 06/28] locking/lockdep: Update obsolete struct field description Yuyang Du
2019-04-24 10:19 ` [PATCH 07/28] locking/lockdep: Use lockdep_init_task for task initiation consistently Yuyang Du
2019-04-24 10:19 ` [PATCH 08/28] locking/lockdep: Define INITIAL_CHAIN_KEY for chain keys to start with Yuyang Du
2019-04-24 10:19 ` [PATCH 09/28] locking/lockdep: Change the range of class_idx in held_lock struct Yuyang Du
2019-04-24 10:19 ` [PATCH 10/28] locking/lockdep: Remove unused argument in validate_chain() and check_deadlock() Yuyang Du
2019-04-24 10:19 ` [PATCH 11/28] locking/lockdep: Update comment Yuyang Du
2019-04-24 10:19 ` [PATCH 12/28] locking/lockdep: Change type of the element field in circular_queue Yuyang Du
2019-04-24 10:19 ` [PATCH 13/28] locking/lockdep: Change the return type of __cq_dequeue() Yuyang Du
2019-04-24 10:19 ` [PATCH 14/28] locking/lockdep: Avoid constant checks in __bfs by using offset reference Yuyang Du
2019-04-24 10:19 ` [PATCH 15/28] locking/lockdep: Update comments on dependency search Yuyang Du
2019-04-24 10:19 ` [PATCH 16/28] locking/lockdep: Add explanation to lock usage rules in lockdep design doc Yuyang Du
2019-04-24 10:19 ` [PATCH 17/28] locking/lockdep: Remove redundant argument in check_deadlock Yuyang Du
2019-04-24 10:19 ` [PATCH 18/28] locking/lockdep: Remove unused argument in __lock_release Yuyang Du
2019-04-24 10:19 ` [PATCH 19/28] locking/lockdep: Optimize irq usage check when marking lock usage bit Yuyang Du
2019-04-25 19:32   ` Peter Zijlstra
2019-04-26  6:57     ` Yuyang Du
2019-04-30 12:11       ` Peter Zijlstra
2019-05-06  3:05         ` Yuyang Du
2019-05-06  3:42           ` Yuyang Du [this message]
2019-05-07  1:47         ` Frederic Weisbecker
2019-05-07  2:21           ` Yuyang Du
2019-04-24 10:19 ` [PATCH 20/28] locking/lockdep: Refactorize check_noncircular and check_redundant Yuyang Du
2019-04-25 19:48   ` Peter Zijlstra
2019-04-26  6:48     ` Yuyang Du
2019-04-24 10:19 ` [PATCH 21/28] locking/lockdep: Consolidate lock usage bit initialization Yuyang Du
2019-04-24 10:19 ` [PATCH 22/28] locking/lockdep: Adjust new bit cases in mark_lock Yuyang Du
2019-04-25 19:52   ` Peter Zijlstra
2019-04-26  6:47     ` Yuyang Du
2019-04-24 10:19 ` [PATCH 23/28] locking/lockdep: Update irqsafe lock bitmaps Yuyang Du
2019-04-25 19:55   ` Peter Zijlstra
2019-04-26  6:45     ` Yuyang Du
2019-04-24 10:19 ` [PATCH 24/28] locking/lockdep: Remove !dir in lock irq usage check Yuyang Du
2019-04-25 20:03   ` Peter Zijlstra
2019-04-26  7:06     ` Yuyang Du
2019-04-26  7:25       ` Boqun Feng
2019-04-30 15:35     ` Peter Zijlstra
2019-04-24 10:19 ` [PATCH 25/28] locking/lockdep: Implement new IRQ usage checking algorithm Yuyang Du
2019-04-24 10:19 ` [PATCH 26/28] locking/lockdep: Remove __bfs Yuyang Du
2019-04-25 20:06   ` Peter Zijlstra
2019-04-26  6:35     ` Yuyang Du
2019-04-24 10:19 ` [PATCH 27/28] locking/lockdep: Remove locks_before Yuyang Du
2019-04-24 10:19 ` [PATCH 28/28] locking/lockdep: Reduce lock_list_entries by half Yuyang Du
2019-04-25 18:56 ` [PATCH 00/28] Optimize IRQ usage checks and other small bits Peter Zijlstra
2019-04-26  6:59   ` Yuyang Du

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHttsrZKx0cgs6t9ahxmV7ENp6QWG4H9N7KMvsgrucQ_rsqTJQ@mail.gmail.com \
    --to=duyuyang@gmail.com \
    --cc=bvanassche@acm.org \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.