All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wessel <jason.wessel@windriver.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH] cooker: bitbake memres server should not always reload the cache
Date: Fri, 28 Mar 2014 10:25:56 -0500	[thread overview]
Message-ID: <53359484.7070707@windriver.com> (raw)
In-Reply-To: <2703747.EGqZ9dGWcs@peggleto-mobl5.ger.corp.intel.com>

On 03/28/2014 09:22 AM, Paul Eggleton wrote:
> On Friday 28 March 2014 07:56:43 Jason Wessel wrote:
>> On 03/28/2014 06:43 AM, Alex Damian wrote:
>>> Please hold merging this change.
>>>
>>> I think we need to discuss a bit on this. My expectation is that the
>>> Bitbake server will reinit its state between builds, re-parsing the
>>> configuration files and reload the cache. I am not sure why we would
>>> consider maintaining the hot cache copy in memory between builds.
>> It is about increasing the interactivity of the system.  There are certainly
>> times you need to soft reset, but perhaps that is what we need to expose. 
>> If I want to run a dev shell and have done a build, this is something I'd
>> like to be instantaneous, or if I am working on the package and want to
>> re-run the compile and package steps, there really is no need to parse.
>>
>> There is a trade off for the individual package work vs the work of
>> rebuilding the entire image.  In the case of the entire image you most
>> certainly want the soft reset behavior.
> To my mind it depends on the likelihood of something having changed and 
> whether that change might affect what you would be doing with the action that 
> follows. For example. if you're trying to fix the execution of a particular 
> task, you would expect to see any change in the recipe / configuration to take 
> effect when re-running the task.

I think there should be a lighter weight way to check then.  I have to believe we could actually check all the time stamps pretty quickly if we have them stored away as a part of the parse for all the files that were touched.  I admit I have not looked a whole lot at what determines when to re-parse / soft reset, but I have to believe we can come up with a light enough way in mem-res mode so as not to pay a reparse toll like we are doing presently.  Perhaps this is what the cache check already does today?

Perhaps you know what all is going on when the bitbake cache is doing its load (which takes ~ 2 seconds or so) for the set of recipes I was interested in.  My goal here is merely to improve the interactivity, assuming it is possible.

Cheers,
Jason.


      reply	other threads:[~2014-03-28 15:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26  8:05 [PATCH] cooker: bitbake memres server should not always reload the cache Cristiana Voicu
2014-03-28 11:43 ` Alex Damian
2014-03-28 12:56   ` Jason Wessel
2014-03-28 14:22     ` Paul Eggleton
2014-03-28 15:25       ` Jason Wessel [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=53359484.7070707@windriver.com \
    --to=jason.wessel@windriver.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.