linux-kernel - Re: [RFC] [Patch 4/4] lock contention tracking slimmed down

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: <466D3148.2050607@de.ibm.com>
Date:	Mon, 11 Jun 2007 13:26:00 +0200
From:	Martin Peschke <mp3@...ibm.com>
To:	"Bill Huey (hui)" <billh@...ppy.monkey.org>
CC:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	a.p.zijlstra@...llo.nl, jbaron@...hat.com, rostedt@...dmis.org,
	linux-s390@...r.kernel.org
Subject: Re: [RFC] [Patch 4/4] lock contention tracking slimmed down

Bill Huey (hui) wrote:
 > However, I don't understand why all of this
 > is so heavy weight when the current measurements that Peter makes is
 > completely sufficient for any reasonable purpose I can think of at the
 > moment.

It wasn't meant to be or to stay heavy weight. To make the best of my
recent attempt: It's good that such issues show up.

 > What's this stuff with labels about ?

Sorry, I didn't come around to posting a documentation update.

It's an optional callback that allows a user to label an entry of
a statistic when it is printed. I have used this feature for adding
symbol strings to instruction pointers.

 > It's important to get the points of contention so that the greater
 > kernel group can fix this issues and not log statistics for the purpose
 > of logging it. The original purpose should not be ignore when working
 > on this stuff.

Sure.

 > By the way, what's the purpose of all of this stuff ? like what do you
 > intend to do with it over the long haul ?

Well, it started as statistics code of a device driver. When I realized
that I was increasing code duplication in the kernel, I tried to abstract
the code out that is device driver independent, allowing others to reuse it.
I have done a couple of iterations, adapting the code to requirements
which showed up when using the code for another driver etc.

This time, my lock contentaion patch showed two issues that require work:
struct statistics needs to be slimmed down or be eliminated alltogether;
allocations might be fine for some users but not for all. Solving
these issues is feasible. Anyway, I don't think I can effort pursueing
it further.

Martin

-
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/