On 07.08.19 19:05, Andrew Cooper wrote:
On 07/08/2019 15:31, Juergen Gross wrote:
Add the cpu currently holding the lock to struct lock_debug. This makes
analysis of locking errors easier and it can be tested whether the
correct cpu is releasing a lock again.
Signed-off-by: Juergen Gross <jgr...@suse.com>
Looking at the structure:
xen.git/xen$ pahole xen-syms -E -C spinlock
struct spinlock {
/* typedef spinlock_tickets_t */ union {
/* typedef u32 */ unsigned int head_tail;
/* 4 */
struct {
/* typedef u16 */ short unsigned int head;
/* 0 2 */
/* typedef u16 */ short unsigned int tail;
/* 2 2 */
};
/* 4 */
} tickets; /* 0 4 */
/* typedef u16 */ short unsigned int recurse_cpu:12;
/* 4: 4 2 */
/* typedef u16 */ short unsigned int recurse_cnt:4;
/* 4: 0 2 */
union lock_debug {
short unsigned int val;
/* 2 */
struct {
short unsigned int unused:1;
/* 6:15 2 */
short unsigned int irq_safe:1;
/* 6:14 2 */
short unsigned int pad:2;
/* 6:12 2 */
short unsigned int cpu:12;
/* 6: 0 2 */
};
/* 2 */
} debug; /* 6 2 */
/* size: 8, cachelines: 1, members: 4 */
/* last cacheline: 8 bytes */
};
we now get two 12-bit CPU fields trying to fit into 4 bytes. Is it
possible to reuse the recurse_cpu field for debugging as well?
I don't think this would be a good idea for two reasons:
- Changing the way recurse_cpu is being used in debug builds might
result in weird behavior in corer cases. That's not what debug
additions are meant for.
- We might be able to save 2 bytes, which will then just be unused.
So no memory saved, but complexity gained.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
