lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 2 Oct 2018 10:10:48 -0400 From: Waiman Long <longman@...hat.com> To: Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org> Cc: Ingo Molnar <mingo@...hat.com>, Will Deacon <will.deacon@....com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 4/5] locking/lockdep: Make class->ops a percpu counter On 10/02/2018 05:55 AM, Ingo Molnar wrote: > * Peter Zijlstra <peterz@...radead.org> wrote: > >> On Fri, Sep 28, 2018 at 01:53:20PM -0400, Waiman Long wrote: >>> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c >>> index ca002c0..7a0ed1d 100644 >>> --- a/kernel/locking/lockdep.c >>> +++ b/kernel/locking/lockdep.c >>> @@ -139,6 +139,7 @@ static inline int debug_locks_off_graph_unlock(void) >>> */ >>> unsigned long nr_lock_classes; >>> static struct lock_class lock_classes[MAX_LOCKDEP_KEYS]; >>> +static DEFINE_PER_CPU(unsigned long [MAX_LOCKDEP_KEYS], lock_class_ops); >>> @@ -1387,11 +1391,15 @@ static inline int usage_match(struct lock_list *entry, void *bit) >>> >>> static void print_lock_class_header(struct lock_class *class, int depth) >>> { >>> - int bit; >>> + int bit, cpu; >>> + unsigned long ops = 0UL; >>> + >>> + for_each_possible_cpu(cpu) >>> + ops += *per_cpu(class->pops, cpu); >>> >>> printk("%*s->", depth, ""); >>> print_lock_name(class); >>> - printk(KERN_CONT " ops: %lu", class->ops); >>> + printk(KERN_CONT " ops: %lu", ops); >>> printk(KERN_CONT " {\n"); >>> >>> for (bit = 0; bit < LOCK_USAGE_STATES; bit++) { >> That is an aweful lot of storage for a stupid number. Some archs >> (sparc64) are bzImage size constrained and this will hurt them. >> >> Ingo, do you happen to remember what that number was good for? > Just a spur of the moment statistics to satisfy curiousity, and it's useful to see how 'busy' a > particular class is, right? > >> Can't we simply ditch it? > We certainly could. Do we have roughly equivalent metrics to arrive at this number via other > methods? > > Thanks, > > Ingo One alternative is to group it under CONFIG_DEBUG_LOCKDEP again. This metric was originally under CONFIG_DEBUG_LOCKDEP, but was moved to CONFIG_LOCKDEP when trying to make other lock debugging statistics per-cpu counters. It was probably because this metric is per lock class while the rests are global. By doing so, you incur the memory cost only when CONFIG_DEBUG_LOCKDEP is defined. What do you think? Cheers, Longman
Powered by blists - more mailing lists