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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>
> > On 7 March 2014 01:32, Todd Fiala <[email protected]> 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
> > [email protected]
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
>
>
> --
> Todd Fiala | Software Engineer | [email protected] | 650-943-3180
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
