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: Fri, 26 Apr 2019 14:57:37 +0800 [thread overview]
Message-ID: <CAHttsrY4jK2cayBE8zNCSJKDAkzLiBb40GVfQHpJi2YK1nEZaQ@mail.gmail.com> (raw)
In-Reply-To: <20190425193247.GU12232@hirez.programming.kicks-ass.net>
Thanks for review.
On Fri, 26 Apr 2019 at 03:32, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Apr 24, 2019 at 06:19:25PM +0800, Yuyang Du wrote:
>
> After only a quick read of these next patches; this is the one that
> worries me most.
>
> You did mention Frederic's patches, but I'm not entirely sure you're
> aware why he's doing them. He's preparing to split the softirq state
> into one state per softirq vector.
>
> See here:
>
> https://lkml.kernel.org/r/20190228171242.32144-14-frederic@kernel.org
> https://lkml.kernel.org/r/20190228171242.32144-15-frederic@kernel.org
>
> 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?
next prev parent reply other threads:[~2019-04-26 6:57 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 [this message]
2019-04-30 12:11 ` Peter Zijlstra
2019-05-06 3:05 ` Yuyang Du
2019-05-06 3:42 ` Yuyang Du
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=CAHttsrY4jK2cayBE8zNCSJKDAkzLiBb40GVfQHpJi2YK1nEZaQ@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).