Project

General

Profile

Actions

Feature #3291

closed

Speed up CIF essentially

Added by Evgeny Novikov over 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
High
Category:
-
Start date:
07/26/2012
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

Recently we have noticed that CIF processes a huge amount of pointcuts for a large program inefficiently. This almost doesn't depend on a representation of pointcuts: either in separate advices or in one advice which join pointcuts with help of '||'.
I think about this and profile CIF a bit. So there are about 20 thousands of ldv_match_cp() calls and about 50 millions of repeated calls of this function for driver usb/serial/aircable.c and model 119_1a. It means that 20 thousands join points in the driver were analyzed by CIF. But, because of the composite pointcut represents disjunction of about 5 thousands of primitive pointcuts, CIF has checked each of join point against 5 thousands of primitive pointcuts. Generally speaking, this should be done, since the given join point can be matched with one of this primitive pointcut. But this time CIF works inefficiently! I guess, that the most of join points analyzed aren't function call, while the model huge composite pointcut consists just of primitive pointcuts on function calls.
To optimize CIF, we can:
  • Derive some information for the given composite pointcut on the basis of its primitive pointcuts at the aspect parsing stage. For instance, we can say that the given composite pointcut is disjunction of just primitive pointcuts on function calls. Then when we will analyze some join point that isn't a function call we will be able quickly understand whether the given composite pointcut can match it or not. With careful aspect developing (e.g. if one will combine all similar primitive pointcuts together with help of disjunction) it will speed up CIF essentially.
  • Analyze join points distribution. I guess that the most of join points are related with variable manipulations. But we haven't models that use set and get poincuts (as well as other associated with variable manipulations)! Thus we can simply omit analysis of variable manipulations in CIF (conditionally). However this approach may be absolutely useless if one will use at least one set or get pointcut in general kernel model that will be included in each rule model.
  • Use both these optimizations.

Files

cpcihp_zt5550.c.macroinstrumented.bz2 (167 KB) cpcihp_zt5550.c.macroinstrumented.bz2 Evgeny Novikov, 10/16/2013 04:03 PM
0123.aspect.i.tar.xz (1.02 MB) 0123.aspect.i.tar.xz Evgeny Novikov, 02/01/2014 10:34 AM
callgrind.out.4746 (992 KB) callgrind.out.4746 Ilya Shchepetkov, 02/04/2014 04:05 PM

Related issues 3 (1 open2 closed)

Related to C Instrumentation Framework - Bug #372: Aspectator and C-backend don't worry about memory releasingClosedEvgeny Novikov08/05/2010

Actions
Related to C Instrumentation Framework - Bug #3323: Internal compiler error in AspectatorClosedFedor Kozlov08/03/2012

Actions
Blocks Linux Kernel Safety RuleDB - Feature #2606: 119: probe functions should not return -EINTROpenVladimir Gratinskiy03/17/2012

Actions
Actions #1

Updated by Evgeny Novikov about 11 years ago

Ilya Shchepetkov detected one more example of very slow work of Aspectator. Corresponding files were attached.

Actions #2

Updated by Evgeny Novikov almost 11 years ago

  • File deleted (0123.aspect.i.bz2)
Actions #3

Updated by Evgeny Novikov almost 11 years ago

Add non broken aspect file.

Actions #4

Updated by Ilya Shchepetkov almost 11 years ago

Added file with some profile information.

Actions #5

Updated by Ilya Shchepetkov almost 11 years ago

In feature-3291 branch I speeded up aspectator's work in case of large generated aspects (like one with might_sleep functions). However, I believe the work is far from complete.

Actions #6

Updated by Evgeny Novikov almost 11 years ago

People optimizes compilers for decades, but still has TODOs. Aspectator is a compiler, so don't worry!

Actions #7

Updated by Evgeny Novikov almost 11 years ago

Actually, to resolve this feature request we just need to check whether your optimizations work for 119_1a specification. And if so it can be closed after merge to the mainline branch.

Other optimizations should be treated in other feature requests.

Actions #8

Updated by Evgeny Novikov over 10 years ago

  • Status changed from Open to Resolved

Unfortunately mentioned tests weren't performed, so don't close the issue although code was merged to master in d1a3cd1.

Actions #9

Updated by Evgeny Novikov over 10 years ago

  • Assignee changed from Ilya Shchepetkov to Evgeny Novikov
Actions #10

Updated by Ilya Shchepetkov over 10 years ago

  • Status changed from Resolved to Closed

Fortunately mentioned tests were performed. 119_1a specification works fine.

Actions #11

Updated by Evgeny Novikov over 10 years ago

  • Assignee changed from Evgeny Novikov to Ilya Shchepetkov

You did it! But what about #3323?

Actions

Also available in: Atom PDF