From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: SF Markus Elfring <elfring@users.sourceforge.net>,
Johannes Berg <johannes@sipsolutions.net>,
linux-kernel@vger.kernel.org, backports@vger.kernel.org,
cocci@systeme.lip6.fr
Subject: Re: [Cocci] [PATCH] coccinelle: add pycocci wrapper for multithreaded support
Date: Fri, 11 Apr 2014 21:00:14 +0200 [thread overview]
Message-ID: <20140411190014.GL14815@wotan.suse.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1404110800120.2032@localhost6.localdomain6>
[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]
On Fri, Apr 11, 2014 at 08:01:04AM +0200, Julia Lawall wrote:
>
>
> On Fri, 11 Apr 2014, SF Markus Elfring wrote:
>
> > > I checked the profile results, the reason the jobs finish is some threads
> > > had no work or little work.
> >
> > Could you find out during the data processing which parts or files
> > result in a special application behaviour you would like to point out here?
>
> I don't understand the question at all, but since the various files have
> different properties, it is hard to determine automatically in advance how
> much work Coccinelle will need to do on each one.
For the person who might work on enhancing multithreading support, I'd wonder
if there could be gains of actually putting an effort out first to evaluate
which files have one rule hit and then adding the file to an activity file lis
to later be spread between the threads. As you note though it is hard to
determine this in advance though given that each rule express any change.
I think one small change which could help, and likely not incur a drastic
immediate change on architecture could be to not let theads take files / jobs
list of files, but instead just take say:
work_task_n = (files / jobs) / 10
The list of files needing work could then be kept on a list protected
against the threads, and each thread will only die if all the files
have been worked on already. This would enable keeping number_cpu
threads only, as each CPU would indeed be busy all the time.
BTW is the patch Acked-by Julia? Can we commit it :)
Luis
[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]
prev parent reply other threads:[~2014-04-11 19:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 17:48 [PATCH] coccinelle: add pycocci wrapper for multithreaded support Luis R. Rodriguez
2014-04-10 17:51 ` Johannes Berg
2014-04-10 17:57 ` Luis R. Rodriguez
2014-04-10 19:32 ` [Cocci] " Julia Lawall
2014-08-28 3:46 ` Luis R. Rodriguez
2014-08-28 18:15 ` Julia Lawall
2014-08-28 20:02 ` Luis R. Rodriguez
2014-04-11 5:55 ` SF Markus Elfring
2014-04-11 6:01 ` [Cocci] " Julia Lawall
2014-04-11 6:15 ` SF Markus Elfring
2014-04-11 19:00 ` Luis R. Rodriguez [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140411190014.GL14815@wotan.suse.de \
--to=mcgrof@suse.com \
--cc=backports@vger.kernel.org \
--cc=cocci@systeme.lip6.fr \
--cc=elfring@users.sourceforge.net \
--cc=johannes@sipsolutions.net \
--cc=julia.lawall@lip6.fr \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox