On 7/17/20 5:44 PM, Christian Brauner wrote:
On Thu, Jul 16, 2020 at 05:03:58PM +0800, Rong Chen wrote:
> On 7/16/20 4:46 PM, Christian Brauner wrote:
>> On Thu, Jul 16, 2020 at 04:40:44PM +0800, kernel test robot wrote:
>>> FYI, we noticed a -8.2% regression of netperf.Throughput_tps due to commit:
>>> commit: ae04f172df5d207dbf185c2ae5c293306ca6a143 ("fs: add
>> That seems odd?
>> Technically there's a bug I fixed in a new version but I'm not sure that
>> would explain this regression.
> Hi Christian,
> Could you tell us the latest commit of this patch? then we can reconfirm it.
Sorry for the delay. I reworked some other things in this branch. :)
So I've pushed to the "mount_setattr" branch on git.kernel.org/brauner
just now. So that should have the fix I was mentioning. Here's the
I have tested the commit aa63af1b08246 "fs: add mount_setattr()",
there's no regression now.
>> Btw, is there a way for me to trigger a build on a branch intentionally
>> and have a guaranteed response in say 1-2 hrs? Ideally a workflow like:
>> - send mail: test this
>> - get mail: acknowledged
>> - get mail: finished/failed etc.
> Hmm, we considered similar plan before, it's hard to finish all tests in a
> short time,
> but it could be archived if only test the patch for a specific test case.
> for example, we only grab the patch replied to report, than test the failed
> and return result to the author.
I think that would work very well indeed. This is similar to how
syzkalle does it afaict.
> Do you have any advice?
I think what I miss the most is to be able to opt-in to a more
interactive workflow. So what I'd want to be able to do is:
- tell the ci system to start a testbuild
- This can either be on a per-request basis, i.e. I can tell the ci
system to start a build on this branch now. Or - which might be
easier for you - I name a dedicated branch or branches that can be
used for this.
- get an acknowledgement mail sent only to my email address that the
request has been received and will be processed
- get an notification when the test has finished
- The important thing to note is that I would like to be notified
about both success and failure so I know the testbuild has run.
This workflow can be completely opt-in. I think quite a few people will
like this and the others won't be affected because it's opt-in.
The problem with the current setup is that I know you're building
branches of mine but I don't know when I triggered a built and I also
don't know whether or not it was successful because the time between me
pushing to a branch, a testbuild starting, and the notification about a
failure of that testbuild can be quite long.
Thanks for your valuable advice, we have monitored many trees,
we can start to test and send the reports to the people if branch updated.
We'll make a plan for "send mail: test this" and "get mail: