Re: Pushing to diverged branches

[Andrew Stubbs]

On 06/05/11 07:11, John Arbash Meinel wrote:

In 2.4b? most commands that took>3min in my testing dropped into the
<30s range because of improved ordering while walking the inventory.
There are still a few more that can be improved a bit further.


Any idea when these improvements are likely to hit the PPA stable release?

I can try out other versions on my local machine, but I won't get it on 
the build server until it's officially stable.


Thanks

Andrew

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Pushing to diverged branches

[Martin Pool]

On 6 May 2011 10:13, Andrew Stubbs  wrote:
> On 06/05/11 07:11, John Arbash Meinel wrote:
>>
>> In 2.4b? most commands that took>3min in my testing dropped into the
>> <30s range because of improved ordering while walking the inventory.
>> There are still a few more that can be improved a bit further.
>
> Any idea when these improvements are likely to hit the PPA stable release?
>
> I can try out other versions on my local machine, but I won't get it on the
> build server until it's officially stable.

2.4 will be frozen in August (ahead of the Ubuntu 11.10 freeze), and
shortly after that it will go into ppa:bzr/ppa.  Before then it's just
the daily and beta ppas.

Martin

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Pushing to diverged branches

[John Arbash Meinel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/5/2011 11:22 PM, Martin Pool wrote:
> On 5 May 2011 18:19, Andrew Stubbs  wrote:
>> On 05/05/11 16:22, Martin Pool wrote:
>>>
>>> I filed  to track
>>> this.  I think it will have been improved a fair bit by John's recent
>>> work on huge-tree workingtree performance work (which sped up some
>>> things like revert 8x) but there's probably more to do.  That work is
>>> in bzr 2.4beta, which you can get from eg ppa:bzr/daily.
>>
>> I certainly have witnessed revert being very slow.
>>
>> In fact, I'd say it feels quicker to run "bzr st" and then do "bzr revert"
>> naming individual files. Maybe that's illusory, but it's certainly quicker
>> to revert individual files if you already have the list to hand. Of course,
>> that doesn't revert merge notes, so it's perhaps not exactly the same.
> 
> I think that's consistent with the bug that was recently fixed.  If
> you still see this in current bzr 2.4beta, please let me know.

It hasn't actually landed yet because the revert patch conflicted with
TreeReferences, which I had an initial fix for, but had yet more fallout
in another section with TreeReferences. (nested-subtrees which is
unfinished work in our codebase.)

I hope to have that finished off and landed today.

> 
>> Uncommit is another command that seems unreasonably slow. It really
>> shouldn't be that hard to do a "patch -R" and update some metadata
>> somewhere, but clearly there's a lot more to it than that!
> 
> I think that's the same.
> 
> Martin

Uncommit has to rewrite the whole dirstate file because we are storing
the inventory of the basis revision to make things like "bzr st" fast.
(uncommit trivially moves the branch pointer, and then
not-quite-so-trivially tells the working tree that it has a new basis
revision.)

It is possible that we could be lighter weight about the basis revision
change. Instead of telling it "you are now pointing at X", tell it "you
are pointing at X, and here is the delta between Y and X".

I think the main issue for uncommit (minutes) is that it would walk the
whole basis inventory from the repository in a bad way. *That* should be
fixed in bzr-2.4b2 (we'll walk the basis inventory in a faster way,
~10s). If we did a delta approach, we could probably get that down to <1s.

Rewriting the dirstate file itself would then be the primary bottleneck,
I think.

In 2.4b? most commands that took >3min in my testing dropped into the
<30s range because of improved ordering while walking the inventory.
There are still a few more that can be improved a bit further.

John
=:->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3DkREACgkQJdeBCYSNAAOELACePl8g7cuomt+Zzdo+iTF0EZ6y
b18An3lbrDbQv9Rv1ZDOVQYUqvBLHbTj
=FD1U
-END PGP SIGNATURE-

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Fwd: Linaro forums replaced by "Ask Linaro"

[Andrew Stubbs]

There's already a couple of tools-related questions on here. We should 
probably make sure we monitor it regularly.


This isn't to hard, once you're signed up, you can mark certain topics 
as 'interesting' and then you'll get email notifications when there's a 
post.


Andrew

 Original Message 
Subject: Linaro forums replaced by "Ask Linaro"
Date: Fri, 06 May 2011 15:58:53 +0200
From: Michael Opdenacker 
Organization: Linaro
To: everyone 

Greetings,

We are pleased to announce the replacement of our forums by a new "Ask
Linaro" service.

Better than forums, we expect this service to bring more questions and
answers, and incite people to join the Linaro community by sharing their
experience.

We count on your participation.

See http://ask.linaro.org/

Cheers,

Michael.

--
Michael Opdenacker - Community Manager
Linaro, http://linaro.org
Cell: +33 621 604 642
IRC: 'opm' in #linaro on irc.freenode.net


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week 18

[Peter Maydell]

RAG:
Red:
Amber:
Green: GSoC QEMU student project approved

Current Milestones:
 | Planned| Estimate   | Actual |
qemu-linaro 2011-05  | 2011-05-19 | 2011-05-19 ||

Historical Milestones:
finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off |
first qemu-linaro release| 2011-02-08 | 2011-02-08 | 2011-02-08 |
qemu-linaro 2011-03  | 2011-03-08 | 2011-03-08 | 2011-03-08 |
qemu-linaro 2011-04  | 2011-04-21 | 2011-04-21 | 2011-04-21 |

(short week, following holiday)

 == merge-correctness-fixes ==
 * some minor patches committed: SPARC build issues, Neon UNDEFs,
   restore base reg properly for Thumb LDMs that abort midway
 * v2 of configure patch to print list of valid targets
 * some work on fixing QEMU FPSCR status flags (last remaining item
   in this blueprint); submitted a patchset fixing everything except
   the various VCVT instructions (which have trickier softfloat bugs)
 * submitted patch fixing NaN behaviour in VMLA/VMLS/VNMLA/VNMLS
 == other ==
 * the Google Summer of Code QEMU project to work on upstreaming
   some of the Android emulator has been approved; I will be mentoring
   Patrick Jackson, who is the student who will be doing this work
 * qemu-linaro 2011-05 is unlikely to have any code changes since 2011-04;
   we might release it anyway just because it's the final one of the cycle

Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus

Absences:
13-19 May: UDS, Budapest
(maybe but unlikely) 15-16 August: QEMU/KVM strand at LinuxCon NA,
Vancouver [LinuxCon proper follows on 17-19th]

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] weekly status

[Ken Werner]

Hi,

 * finished libunwind support of detection and handling of signal frames on 
ARM Linux. RT and non-RT signal frames are handled for both >=2.6.18 and 
<2.6.18 kernels. The *test-resume-sig testcases are passing now.
 * briefly looked into what needs to be done in order to add 64bit __sync_* 
ops
 * prepared for LDS

Regards
Ken

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Weekly status

[Richard Sandiford]

== This week ==

* Committed interleaved load/store vectorisation changes upstream.

* Merged the vldN and vstN intrinsic improvements into Linaro 4.5 and 4.6.
  (Thanks for the quick reviews here.)

* Backported the interleaved load/store vectorisation changes to Linaro
  4.5 and 4.6.  This took a while because the patch series touches
  turbulent code.  Submitted merge requests.

* Merged Sergey Grechanik's NEON reload improvement into Linaro 4.5
  and 4.6.

* Got ready for summit.

Richard

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 2011-05-06

[David Gilbert]

== Bug fighting ==
  * Tracked bug 774175 (apt segfault on armel on oneiric) down to the
cortex-a8 branch erratum bug that we found as part of the bug jam a
few weeks
ago (affecting the more obscure vtk package) - Richard's existing
binutils fix should fix this.

== String routines ==
  * Struggled to get 'perf' to get sane results from profiling spec;
some of the samples are obviously being associated with the wrong
process somewhere
along the process (e.g. it's showing significant samples in the sh
process but in a library that's used by the actual benchmark.

  * latrace on spec still running on ursa2

  * Wrote a non-neon memcpy; as expected it's aligned performance is
very similar to libc/kernel - it's a bit faster in some places but
slower
in some odd places (e.g. n*32+1 bytes is a lot slower for some
reason).  It's also really bad on mis-aligned cases, I tried to take
advantage
of the v7's ability to do misaligned loads - but they really are quite slow.

Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain