[lkml]   [2010]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] perf lock: Drop "-a" option from set of default arguments to cmd_record()
On 05/11/10 15:48, Frederic Weisbecker wrote:

>>> I think I'm going to unearth the injection code to reduce the size
>>> of these events.
>> Yeah, injection will be really helpful thing.
>> And I have a rough idea for reducing event frequency.
>> Many lock event sequences are like this form:
>> * acquire -> acquired -> release
>> * acquire -> contended -> acquired -> release
>> I think that making 3 or 4 events per each lock sequences
>> is waste of CPU time and memory space.
>> If threads store time of each events
>> and make only 1 event at time of release,
>> we will be able to reduce lots of time and space.
>> For example, ID of each lock instance is 8 byte in x86_64.
>> In this scheme 8 * 4 byte for ID will be only 8 byte.
>> I think this optimization has worth to consider because of
>> high frequency of lock events.
>> How do you think?
> You're right, we could optimize the lock events sequence layout.
> What I'm afraid of is to break userspace, but ripping the name from
> the lock events while introducing injection will break userspace
anyway :-(

Really? For me, at least ripping the name with injection
doesn't make bad things for userspace.
What does the word "break" mean in this context?

> May be we can think about providing new lock events and announce the
> deprecation of the old ones and remove them later. I'm not sure yet.
> But summing up in only one event is not possible. Having only one
> lock_release event (and a lock init for name mapping) is suitable
> for latency measurements only (timestamp + lock addr + wait time +
> acquired time).
> And once you dig into finer grained analysis like latency induced
> by dependencies (take lock A and then take lock B under A, latency
> of B depends of A), then you're screwed, because you only know
> you've released locks at given times but you don't know when you
> acquired them, hence you can't build a tree of dependencies with
> sequences inside.

In my imagination, composing 3 or 4 events into one is meaning
timestamp of itself(it is also one of release) + lock addr
+ timestamp of acquire + timestamp of acquired
(+ timestamp of contended) + misc information
like flags.

I'd like to call this new event as "batch event" in below.

If perf lock reads one batch event, original events of 3 or 4
can be reconstructed in userspace.
So I think dependency relation between locks can be obtained
with sorting reconstructed events with timestamp.

For this way, each threads have to hold memory for
size of batch event * MAX_LOCK_DEPTH.

I'm not sure about possibility and effect of this way :(
and if I misunderstood something about your opinion, please correct me

> Ideally, I think that we need to remove lock contended and only
> trigger lock_acquired when we contended. We obviously don't need
> lock_contended/lock_acquired if the lock wasn't contended.

Yeah, lock events can be reduced more.

> We could even remove lock_acquire and only play with lock_acquired,
> changing a bit the rules, but that will make us lose all the dependencies
> "intra-lock". I mean there are locks which slowpath are implemented
on top
> of other locks: mutexes use mutex->wait_lock spinlock for example.

Do you mean that the relation like acquire(mutex) -> acquire(spinlock)
-> acquired(spinlock) -> acquired(mutex) -> release(spinlock)
will be lost?

It seems taht locks on other locks are only mutex and rwsem.
I think that we have a way to rewrite their lock events
of mutex and rwsem for intra-lock dependencies.

But I cannot measure the actual cost of it :(
So I cannot say easily this is possible...

 \ /
  Last update: 2010-05-12 12:25    [W:0.070 / U:26.276 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site