linux-kernel - Re: [Announce] Development release 0.1 of the LatencyTOP tool

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4790F172.5070907@linux.intel.com>
Date:	Fri, 18 Jan 2008 10:35:30 -0800
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Roberto Fichera <kernel@...no-soft.it>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Announce] Development release 0.1 of the LatencyTOP tool

Roberto Fichera wrote:
> At 18.36 18/01/2008, Arjan van de Ven wrote:
>> The Intel Open Source Technology Center is pleased to announce the
>> release of version 0.1 of LatencyTOP, a tool for developers to visualize
>> system latencies.
>>
>> http://www.latencytop.org
>>
> 
> [...snip...]
> 
>> The most basic annotation looks like this (in the patches more complex
>> versions can be seen):
>>
>>  asmlinkage long sys_sync(void)
>>  {
>> +       struct latency_entry reason;
>> +       set_latency_reason("sync system call", &reason);
>>         do_sync(1);
>> +       restore_latency_reason(&reason);
>> +
>>         return 0;
>>  }
>>
> 
> I really like this patch :-)! Just a little note, why don't make 
> the parameter 'char *reason' as simple integer (reason_t)? 
> Making it as integer will automatically drop the strncmp() 
> and speeding up all the things. Could be also interesting to 
> define _externally_ the mapping of the reason so the 
> userspace tool could handle it easily.
> 

I thought about that, but the strncmp is still somewhat needed to deal with the argument
(the instrumentation above doesn't use that, but the mutex one does for example)
If we get rid of the argument entirely it'd be easier
(but then we get "blocking on mutex" rather than "blocking on inode->mutex")
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/