From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <longman@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org,
Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH 4/5] locking/lockdep: Reuse free chain_hlocks entries
Date: Fri, 13 Dec 2019 11:50:42 +0100 [thread overview]
Message-ID: <20191213105042.GJ2871@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191213102525.GA2844@hirez.programming.kicks-ass.net>
On Fri, Dec 13, 2019 at 11:25:25AM +0100, Peter Zijlstra wrote:
> void push_block(struct chain_block **bp, struct chain_block *b)
> {
> b->next = *bp;
> *bp = b;
> }
>
> /* could contemplate ilog2() buckets */
> int size2bucket(int size)
> {
> return size >= MAX_BUCKET ? 0 : size;
> }
If you make the allocation granularity 4 entries, then you can have
push_block() store the chain_block * at the start of every free entry,
which would enable merging adjecent blocks.
That is, if I'm not mistaken these u16 chain entries encode the class
index (per lock_chain_get_class()). And since the lock_classes array is
MAX_LOCKDEP_KEYS, or 13 bits, big, we have the MSB of each entry spare.
union {
struct {
u16 hlock[4];
}
u64 addr;
} ponies;
So if we make the rule that:
!(idx % 4) && (((union ponies *)chain_hlock[idx])->addr & BIT_ULL(63))
encodes a free block at said addr, then we should be able to detect if:
chain_hlock[b->base + b->size]
is also free and merge the blocks.
(we just have to fix up the MSB of the address, not all arches have
negative addresses for kernel space)
next prev parent reply other threads:[~2019-12-13 10:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 22:35 [PATCH 0/5] locking/lockdep: Reuse zapped chain_hlocks entries Waiman Long
2019-12-12 22:35 ` [PATCH 1/5] locking/lockdep: Track number of zapped classes Waiman Long
2019-12-12 22:35 ` [PATCH 2/5] locking/lockdep: Track leaked chain_hlocks entries Waiman Long
2019-12-12 22:35 ` [PATCH 3/5] locking/lockdep: Track number of zapped lock chains Waiman Long
2019-12-12 22:35 ` [PATCH 4/5] locking/lockdep: Reuse free chain_hlocks entries Waiman Long
2019-12-13 10:25 ` Peter Zijlstra
2019-12-13 10:50 ` Peter Zijlstra [this message]
2019-12-13 16:02 ` Waiman Long
2019-12-13 16:05 ` Waiman Long
2019-12-13 18:12 ` Peter Zijlstra
[not found] ` <7ca26a9a-003f-6f24-08e4-f01b80e3e962@redhat.com>
2019-12-13 18:47 ` Peter Zijlstra
2019-12-13 20:08 ` Waiman Long
2019-12-15 17:06 ` Waiman Long
2019-12-13 15:02 ` Waiman Long
2019-12-13 18:43 ` Peter Zijlstra
2019-12-12 22:35 ` [PATCH 5/5] locking/lockdep: Decrement irq context counters when removing lock chain Waiman Long
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=20191213105042.GJ2871@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--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