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]
Date:	Mon, 4 Dec 2006 09:08:56 -0800
From:	Bill Huey (hui) <billh@...ppy.monkey.org>
To:	bert hubert <bert.hubert@...herlabs.nl>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Cc:	"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: [PATCH 0/4] lock stat for 2.6.19-rt1

On Mon, Dec 04, 2006 at 01:21:29PM +0100, bert hubert wrote:
> On Sun, Dec 03, 2006 at 05:53:23PM -0800, Bill Huey wrote:
> 
> > [8264, 996648, 0]		{inode_init_once, fs/inode.c, 196}
> > [8552, 996648, 0]		{inode_init_once, fs/inode.c, 193}
> 
> Impressive, Bill!
> 
> How tightly is your work bound to -rt? Iow, any chance of separating the
> two? Or should we even want to?

Right now, it's solely dependent on -rt, but the basic mechanisms of how
it works is pretty much the same as lockdep. Parts of it should be
moveable across to regular kernels. The only remaining parts would be
altering the lock structure (spinlock, mutex, etc...) to have a pointer
that it can use to do the statistical tracking. If it's NULL then it's
dunamically allocated and handled differently and allocated when the
lock is contended against.

There's other uses for it as well. Think about RCU algorithms that need
to spin-try to make sure the update of an element or the validation of
it's data is safe to do. If an object was created to detect those spins
it'll track what is effectively contention as well as it is represented
in that algorithm. I've seen an RCU radix tree implementation do something
like that.

> > The first column is the number of the times that object was contented against.
> > The second is the number of times this lock object was initialized. The third
> > is the annotation scheme that directly attaches the lock object (spinlock,
> > etc..) in line with the function initializer to avoid the binary tree lookup.
> 
> I don't entirely get the third item, can you elaborate a bit?

I hate the notion of a search, so I directly set the pointer to a
object that's statically defined. It means that the object is directly
connected to what is suppose to backing it without doing a runtime
search.  When that's done, all of the numbers from the second column
get moved to the third.
 
> Do you have a feeling of the runtime overhead?

There's minimal runtime overhead I believe since it's only doing an
atomic increment of the stats during the slowpath before the thread
is actually shoved into a wait queue. That's something that happpens
seldomly.

bill

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ