Messages in this thread | | | Date | Wed, 12 May 2010 19:23:23 +0900 | From | Hitoshi Mitake <> | Subject | Re: [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...
| |