[lldb-dev] [PATCH] make dosep.ty test driver multi-threadable

[Todd Fiala]

Nice.


On Mon, Mar 17, 2014 at 10:33 AM, Greg Clayton <gclayton at apple.com> wrote:

> Yes, we can either do that via python directly, or through SBHostOS, as
> internally we have:
>
>     static uint32_t Host::GetNumberCPUS ();
>
>
>
> On Mar 17, 2014, at 10:21 AM, Todd Fiala <tfiala at google.com> wrote:
>
> > That's worth a try.
> >
> > I don't yet have any insight into exactly what's wrong with the one I'm
> seeing (or the additional failures that Ed is seeing on FreeBSD), so I'm
> not yet sure if this will address it.  But it does seem worth a try.
> >
> > In the event that your idea works out to eliminate those failures, there
> is another element we can consider.  We can have Python give us the # cores
> available (if there's something portable to do that), and when not
> otherwise specified, pick a reasonable default # threads to get decent test
> run performance without needing the environment  variable specified.  This
> would give anybody running the tests a decent test run speedup without
> having to read docs on configuring the environment variable.  (I think this
> was Steve Pucci's idea but definitely something we discussed.)
> >
> >
> > On Mon, Mar 17, 2014 at 10:12 AM, Greg Clayton <gclayton at apple.com>
> wrote:
> > Maybe we can mark certain tests with a decorator so they get serially
> run after all other parallel tests have completed?
> >
> > Maybe "@serializeTest"?
> >
> >
> >
> > On Mar 17, 2014, at 7:16 AM, Ed Maste <emaste at freebsd.org> wrote:
> >
> > > On 7 March 2014 01:32, Todd Fiala <tfiala at google.com> wrote:
> > >> Steve's change went in earlier today.
> > >>
> > >>> This doesn't yet work with ninja makes, but tfiala or I will look at
> that
> > >>> as well.
> > >>
> > >> I did look into this and it actually works fine without modification
> if you
> > >> do the 'ninja check-lldb' with the environment variable set.
> > >>
> > >> This was the run I just did using 32 procs:
> > >>
> > >> Running multithreaded with 32 threads.
> > >> Ran 278 tests.
> > >>
> > >> real    1m22.855s
> > >> user    5m38.520s
> > >> sys     0m51.520s
> > >>
> > >>
> > >> That used to take 10+ minutes.
> > >
> > > For reference, these are the test times I see on FreeBSD (after
> > > including a PoC patch for llvm.org/pr18894)
> > >
> > > 1 thread:        443.49 real       214.02 user        63.72 sys
> > > 4 threads:      121.17 real       234.17 user        66.27 sys
> > > 8 threads:       88.70 real       305.37 user        92.82 sys
> > >
> > > I see occasional test failures with higher thread settings (I believe
> > > this was mentioned on the list before).  These are the ones that seem
> > > susceptible:
> > >
> > > FAIL: LLDB (suite) :: TestCallThatRestarts.py
> > > FAIL: LLDB (suite) :: TestWatchpointConditionCmd.py
> > > FAIL: LLDB (suite) :: TestWatchpointConditionAPI.py
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> >
> >
> > --
> > Todd Fiala |   Software Engineer |     tfiala at google.com |
> 650-943-3180
> >
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140317/a559b42b/attachment.html>