Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1384845 > unrolled thread

Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Peter Zijlstra <peterz@infradead.org> - 2016-04-22 11:50 +0200
    Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Fengguang Wu <fengguang.wu@intel.com> - 2016-04-22 15:00 +0200
      Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Will Deacon <will.deacon@arm.com> - 2016-04-22 15:10 +0200
      Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Peter Zijlstra <peterz@infradead.org> - 2016-04-22 16:30 +0200
        Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Fengguang Wu <fengguang.wu@intel.com> - 2016-04-23 04:00 +0200
      Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Kalle Valo <kvalo@codeaurora.org> - 2016-04-22 20:40 +0200
        Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Fengguang Wu <fengguang.wu@intel.com> - 2016-04-23 05:30 +0200

#1384845 — Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

On Fri, Apr 22, 2016 at 11:04:13AM +0200, Peter Zijlstra wrote:
> The one that I did not do was ARMv8.1-LSE and I was hoping Will would help out
> with that. Also, it looks like the 0-day built bot does not do arm64 builds,
> people might want to look into that.

OK, weirdness. I received the "BUILD SUCCESS" email without any arm64
builds listed, but I just received a build bot email telling me the
arm64 build was borked (which I know it is).

[toc] | [next] | [standalone]

#1385132

On Fri, Apr 22, 2016 at 11:44:55AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 22, 2016 at 11:04:13AM +0200, Peter Zijlstra wrote:
> > The one that I did not do was ARMv8.1-LSE and I was hoping Will would help out
> > with that. Also, it looks like the 0-day built bot does not do arm64 builds,
> > people might want to look into that.
> 
> OK, weirdness. I received the "BUILD SUCCESS" email without any arm64
> builds listed, but I just received a build bot email telling me the
> arm64 build was borked (which I know it is).

Sorry, that may happen because even though most errors will be
detected in the first hour or before the BUILD SUCCESS/DONE
notification, the build/boot/performance tests for a particular branch
may continue for days, during the time test coverage keeps growing.
Which means it's possible to receive a build failure after receiving
BUILD SUCCESS notification.

In particular, 0-day bot classify 500+ kconfigs into 2 priority lists:

P1: 100+ realtime priority kconfigs which should be finished before sending
    out BUILD SUCCESS notification

P2: 400+ background priority kconfigs which may take hours to days to finish

That split is a tradeoff between timeliness and completeness. It turns
out to work well as long as we choose the suitable P1 list.

So the more accurate interpretation of "BUILD SUCCESS/DONE" would be:
0day bot is working on your tree (no worry about out-of-service) and
reached a major milestone.

I'll add arm64-defconfig to P1 list to improve its coverage.

Thanks,
Fengguang

[toc] | [prev] | [next] | [standalone]

#1385145

On Fri, Apr 22, 2016 at 08:56:56PM +0800, Fengguang Wu wrote:
> On Fri, Apr 22, 2016 at 11:44:55AM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 22, 2016 at 11:04:13AM +0200, Peter Zijlstra wrote:
> > > The one that I did not do was ARMv8.1-LSE and I was hoping Will would help out
> > > with that. Also, it looks like the 0-day built bot does not do arm64 builds,
> > > people might want to look into that.
> > 
> > OK, weirdness. I received the "BUILD SUCCESS" email without any arm64
> > builds listed, but I just received a build bot email telling me the
> > arm64 build was borked (which I know it is).
> 
> Sorry, that may happen because even though most errors will be
> detected in the first hour or before the BUILD SUCCESS/DONE
> notification, the build/boot/performance tests for a particular branch
> may continue for days, during the time test coverage keeps growing.
> Which means it's possible to receive a build failure after receiving
> BUILD SUCCESS notification.
> 
> In particular, 0-day bot classify 500+ kconfigs into 2 priority lists:
> 
> P1: 100+ realtime priority kconfigs which should be finished before sending
>     out BUILD SUCCESS notification
> 
> P2: 400+ background priority kconfigs which may take hours to days to finish
> 
> That split is a tradeoff between timeliness and completeness. It turns
> out to work well as long as we choose the suitable P1 list.
> 
> So the more accurate interpretation of "BUILD SUCCESS/DONE" would be:
> 0day bot is working on your tree (no worry about out-of-service) and
> reached a major milestone.
> 
> I'll add arm64-defconfig to P1 list to improve its coverage.

That's good to hear, thanks Fengguang!

Will

[toc] | [prev] | [next] | [standalone]

#1385223

On Fri, Apr 22, 2016 at 08:56:56PM +0800, Fengguang Wu wrote:
> I'll add arm64-defconfig to P1 list to improve its coverage.

Thanks; any more architectures missing from P1?

[toc] | [prev] | [next] | [standalone]

#1385555

On Fri, Apr 22, 2016 at 04:23:03PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 22, 2016 at 08:56:56PM +0800, Fengguang Wu wrote:
> > I'll add arm64-defconfig to P1 list to improve its coverage.
> 
> Thanks; any more architectures missing from P1?

Good question! Just double checked and find s390 still missing.
All other supported archs have corresponding kconfigs in the P1 list:

alpha-defconfig
arm64-allnoconfig
arm64-defconfig
arm-allnoconfig
arm-at91_dt_defconfig
arm-efm32_defconfig
arm-exynos_defconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
arm-shmobile_defconfig
arm-sunxi_defconfig
avr32-atngw100_defconfig
avr32-atstk1006_defconfig
blackfin-BF526-EZBRD_defconfig
blackfin-BF533-EZKIT_defconfig
blackfin-BF561-EZKIT-SMP_defconfig
blackfin-defconfig
blackfin-TCM-BF537_defconfig
cris-etrax-100lx_v2_defconfig
frv-defconfig
i386-alldefconfig
i386-allmodconfig
i386-allnoconfig
i386-allyesconfig
i386-defconfig
i386-tinyconfig
ia64-alldefconfig
ia64-allnoconfig
ia64-defconfig
m32r-m32104ut_defconfig
m32r-mappi3.smp_defconfig
m32r-opsput_defconfig
m32r-usrv_defconfig
m68k-m5475evb_defconfig
m68k-multi_defconfig
m68k-sun3_defconfig
microblaze-mmu_defconfig
microblaze-nommu_defconfig
mips-allnoconfig
mips-defconfig
mips-fuloong2e_defconfig
mips-jz4740
mips-txx9
mn10300-asb2364_defconfig
openrisc-or1ksim_defconfig
parisc-allnoconfig
parisc-b180_defconfig
parisc-c3000_defconfig
parisc-defconfig
powerpc-allnoconfig
powerpc-defconfig
powerpc-ppc64_defconfig
sh-allnoconfig
sh-defconfig
sh-rsk7269_defconfig
sh-sh7785lcr_32bit_defconfig
sh-titan_defconfig
sparc64-allnoconfig
sparc64-defconfig
sparc-defconfig
tile-tilegx_defconfig
um-i386_defconfig
um-x86_64_defconfig
x86_64-acpi-redef
x86_64-allmodconfig
x86_64-allyesdebian
x86_64-lkp
x86_64-nfsroot
x86_64-rhel
x86_64-rhel_gcov
xtensa-common_defconfig
xtensa-iss_defconfig

I'll add s390-default_defconfig to the above list.  Architecture
maintainers are welcome to suggest more suitable list of configs!

Thanks,
Fengguang

[toc] | [prev] | [next] | [standalone]

#1385429

Fengguang Wu <fengguang.wu@intel.com> writes:

>> OK, weirdness. I received the "BUILD SUCCESS" email without any arm64
>> builds listed, but I just received a build bot email telling me the
>> arm64 build was borked (which I know it is).
>
> Sorry, that may happen because even though most errors will be
> detected in the first hour or before the BUILD SUCCESS/DONE
> notification, the build/boot/performance tests for a particular branch
> may continue for days, during the time test coverage keeps growing.
> Which means it's possible to receive a build failure after receiving
> BUILD SUCCESS notification.
>
> In particular, 0-day bot classify 500+ kconfigs into 2 priority lists:
>
> P1: 100+ realtime priority kconfigs which should be finished before sending
>     out BUILD SUCCESS notification
>
> P2: 400+ background priority kconfigs which may take hours to days to finish
>
> That split is a tradeoff between timeliness and completeness. It turns
> out to work well as long as we choose the suitable P1 list.
>
> So the more accurate interpretation of "BUILD SUCCESS/DONE" would be:
> 0day bot is working on your tree (no worry about out-of-service) and
> reached a major milestone.

Thanks, this is very useful information. But would it be also possible
to get a report about the P2 completion (or failure)?

-- 
Kalle Valo

[toc] | [prev] | [next] | [standalone]

#1385564

On Fri, Apr 22, 2016 at 09:35:06PM +0300, Kalle Valo wrote:
> Fengguang Wu <fengguang.wu@intel.com> writes:
> 
> >> OK, weirdness. I received the "BUILD SUCCESS" email without any arm64
> >> builds listed, but I just received a build bot email telling me the
> >> arm64 build was borked (which I know it is).
> >
> > Sorry, that may happen because even though most errors will be
> > detected in the first hour or before the BUILD SUCCESS/DONE
> > notification, the build/boot/performance tests for a particular branch
> > may continue for days, during the time test coverage keeps growing.
> > Which means it's possible to receive a build failure after receiving
> > BUILD SUCCESS notification.
> >
> > In particular, 0-day bot classify 500+ kconfigs into 2 priority lists:
> >
> > P1: 100+ realtime priority kconfigs which should be finished before sending
> >     out BUILD SUCCESS notification
> >
> > P2: 400+ background priority kconfigs which may take hours to days to finish
> >
> > That split is a tradeoff between timeliness and completeness. It turns
> > out to work well as long as we choose the suitable P1 list.
> >
> > So the more accurate interpretation of "BUILD SUCCESS/DONE" would be:
> > 0day bot is working on your tree (no worry about out-of-service) and
> > reached a major milestone.
> 
> Thanks, this is very useful information. But would it be also possible
> to get a report about the P2 completion (or failure)?

Good question! I'm not sure people would care (or even be confused)
about a report that arrive after days, however based on some statistic
data we may find the suitable time to wait for possible error reports.

The past reports show that about 60% errors are reported in 2 hours,
90% errors are reported in 24 hours and there are 1% errors reported
after 1 week.

So developers may reasonably wait for 1 day before sending out patches.

Thanks,
Fengguang

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web