[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/4] xen/spinlocks: in debug builds store cpu holding the lock
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 <jgross@xxxxxxxx>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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |