[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Patch] support of lock profiling in Xen

  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Thu, 08 Oct 2009 10:27:38 +0200
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 08 Oct 2009 01:28:02 -0700
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=s3U4DVXKQYZwqBRYLtXa08IBTRL7uHMIJ5LY3Q/8ANa//HG8aiRufzv+ I0gW1TnW9k1YwQQLsC2Zq8LMWoloWyOZonK9IynJAAdgHe2ohyAJDEizx /aZ0qQfdG7xhycwVNQ5NDidlQH6rFI36bljYUGepo76xz7mdksyGeg6ly DQcMxHLO6tD1NcTUOSza3W8zla5eFUXO8LZ1NSKy0jaGudgfbjLMyRI0F CHGd/qPRyMWYSIlkdX2SeUPWGtIJN;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Keir Fraser wrote:
> On 08/10/2009 08:48, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:
>> I'm not completely satisfied with the solution for the dynamically 
>> initialized
>> locks, but I had no better idea in the first run.
>> Another enhancement would be to expand the profiling to rw-locks as well, but
>> this would have required a rewrite of the lock routines using try_lock like
>> for spinlocks. I could do this if the lock profiling is accepted.
>> Comments welcome :-)
> The method of chaining and initialising the info is kind of icky. Requiring
> users to unchain dynamic locks is just asking for this support to be
> perpetually broken, or be used only for static locks.
> How about defining new initialisers DEFINE_NAMED_SPINLOCK() and
> named_spinlock_init(). This would indicate you consider a lock important
> enough to name (and hence profile) and also categorise dynamically-allocated
> locks, causing their stats to be aggregated (after all, lock optimisations
> will have aggregate effect across all locks of that category).
> If lock profiling is compiled in, have a static array of lock-profile
> descriptors (keeps things simple - could make it a growable array, or
> something). On lock init, walk the array looking for that name. If found,
> write the entry index into a new field in the spinlock struct. If not found,
> allocate next entry in lock-profile array, init it, and write its index into
> the spinlock struct.

Don't you think a solution like for performance counters would be better then?
The index would be in a header file and the sums could be held per-cpu to
avoid races.
It would even be possible to define lock arrays if summing up all data for
e.g. domain specific locks is not desired.

> On lock operations, if the index field in the spinlock is non-zero, update
> stats in the associated profile structure. Regarding races from locks
> aliasing to the same profile structure -- either assume that doesn't matter
> much, or perhaps update fields with atomic ops.


Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions               e-mail: juergen.gross@xxxxxxxxxxxxxx
Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
D-81739 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.