All of lore.kernel.org
 help / color / mirror / Atom feed
From: "chris.laplante@agilent.com" <chris.laplante@agilent.com>
To: Joshua Watt <jpewhacker@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Cache unihash ... doesn't match BB_UNIHASH ...
Date: Wed, 12 Feb 2020 16:51:17 +0000	[thread overview]
Message-ID: <BN6PR1201MB2482BB5FBC50F4233211BDFB8B1B0@BN6PR1201MB2482.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAJdd5GZ7De+yGrCitp4rcPQs+suZdHS+7N4c9N1gdG-6V-deZA@mail.gmail.com>

> One is occasionally I get a lot of undeterministic metadata errors when BB_CACHE_POLICY = "cache", multiconfig, and hash equiv are
> enabled. The errors are all on recipes for which SRCREV = "${AUTOREV}". It doesn't always happen. But it did just now when I rebased
> our "zeus-modified" branch onto the upstream "zeus" branch, to get the changes starting with
> 7dc72fde6edeb5d6ac6b3832530998afeea67cbc.
> 
> Two is that, sometimes "Initializing tasks" stage appears stuck at 44% for a couple minutes. I traced it down to this code in
> runqueue.py (line 1168 on zeus):
> 
>         # Iterate over the task list and call into the siggen code
>         dealtwith = set()
>         todeal = set(self.runtaskentries)
>         while len(todeal) > 0:
>             for tid in todeal.copy():
>                 if len(self.runtaskentries[tid].depends - dealtwith) == 0:
>                     dealtwith.add(tid)
>                     todeal.remove(tid)
>                     self.prepare_task_hash(tid)
> 
> When I instrument the loop to print out the size of "todeal", I see it decrease very slowly, sometimes only a couple at a time. I'm
> guessing this is because prepare_task_hash is contacting the hash equiv server, in a serial manner here. I'm over my work VPN which
> makes things extra slow. Is there an opportunity for batching here?
> 
> Batching is hard because the hashes you request might depend on hashes previous received from the server. It might be possible to
> figure out these dependencies and submit multiple batch requests, but this would require some work in the code. Another option
> would be to have some multi-level caching scheme where you can have a local database that mirrors your centralized server.
> 
> If you have any ideas on how to make it faster, we would love to hear your opinion :)


Gotcha, unfortunately I don't have any ideas right now :/. Regarding the first issue, any ideas there?

Thanks,
Chris


      reply	other threads:[~2020-02-12 16:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07  8:16 Cache unihash ... doesn't match BB_UNIHASH Alex Kiernan
2020-02-07  8:31 ` Richard Purdie
2020-02-07  9:12   ` Alex Kiernan
2020-02-07 14:43   ` chris.laplante
2020-02-07 15:05     ` Richard Purdie
2020-02-07 15:08       ` chris.laplante
2020-02-07 15:44       ` Alex Kiernan
2020-02-09  0:23         ` chris.laplante
2020-02-09  7:27           ` Alex Kiernan
2020-02-09 16:25             ` Alex Kiernan
2020-02-10 14:22               ` Alex Kiernan
2020-02-09 16:37           ` Joshua Watt
2020-02-12 16:51             ` chris.laplante [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=BN6PR1201MB2482BB5FBC50F4233211BDFB8B1B0@BN6PR1201MB2482.namprd12.prod.outlook.com \
    --to=chris.laplante@agilent.com \
    --cc=jpewhacker@gmail.com \
    --cc=openembedded-core@lists.openembedded.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 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.