Date: Wed, 29 Jul 2015 19:18:34 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Warner Losh <imp@bsdimp.com> Cc: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <royger@FreeBSD.org>, Adrian Chadd <adrian.chadd@gmail.com>, Warner Losh <imp@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Shani Michaeli <shanim@mellanox.com> Subject: Re: svn commit: r285068 - in head/sys: conf modules/agp modules/geom/geom_part/geom_part_apm modules/geom/geom_part/geom_part_bsd modules/geom/geom_part/geom_part_bsd64 modules/geom/geom_part/geom_part... Message-ID: <55B90AEA.2040806@selasky.org> In-Reply-To: <2779441E-E53E-4DB4-84CF-36A0CFCB4C08@bsdimp.com> References: <201507030150.t631oRd0039490@repo.freebsd.org> <5596C188.10404@FreeBSD.org> <CAJ-VmomcHt_RiDRDC3s8_sjQXyOfh5yrNQjOxOEp-re1ceb2yQ@mail.gmail.com> <5596C7E7.5090700@FreeBSD.org> <68C8F69B-56DF-45C3-8DBB-40514CA48D85@bsdimp.com> <55B8A8CA.90701@selasky.org> <3414D44A-A22F-4693-9F84-A8E880C0B185@bsdimp.com> <55B8F547.2010008@selasky.org> <2779441E-E53E-4DB4-84CF-36A0CFCB4C08@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/29/15 18:59, Warner Losh wrote: > >> On Jul 29, 2015, at 9:46 AM, Hans Petter Selasky <hps@selasky.org> wrote: >> >> On 07/29/15 16:24, Warner Losh wrote: >>> >>>> On Jul 29, 2015, at 4:19 AM, Hans Petter Selasky <hps@selasky.org> wrote: >>>> >>>> On 07/03/15 22:15, Warner Losh wrote: >>>>> >>>>>> On Jul 3, 2015, at 11:35 AM, Roger Pau Monné <royger@FreeBSD.org> wrote: >>>>>> >>>>>> El 03/07/15 a les 19.26, Adrian Chadd ha escrit: >>>>>>> ok, so why's it make NFS builds so slow? >>>>>> >>>>>> AFAICT it makes the build process spawn a bunch of concurrent "find" >>>>>> processes that weren't previously there. >>>>> >>>>> OK. I’ll fix it. I knew it might slow things down a little, but this is quite a bit more than “a little”. >>>>> >>>>> Warner >>>>> >>>> >>>> Hi, >>>> >>>> Is there a fix for this issue yet? At Mellanox we're also seeing that NFS mounted shares are extremely slow building even a single module. Maybe the output from the find can be cached in a file somehow? >>> >>> Committed the fix within a day of this message (so three weeks ago): >>> >>> https://svnweb.freebsd.org/base?view=revision&revision=285124 >>> >>> Is it not working? this is the first negative report I’ve heard since Adrian and Roger posted. I spiked the test-build with a find that recorded every time it ran. W/o the fix, it runs a lot. With the fix it ran once. Is this not the case still? >> >> Hi, >> >> In this particular case one "find of /sys" takes 11-16 seconds over NFS, so building a single KMOD takes 16 seconds too. It's not possible to eliminate the find entirely during repeated builds? > > 16 seconds? That’s a really slow NFS server and at least 11 seconds longer than it should take :(. Hi, I think it is a local NFS caching issue. Else it would be faster. BTW: I think I see a small typo there: > Index: kmod.mk > =================================================================== > --- kmod.mk (revision 286002) > +++ kmod.mk (working copy) > @@ -361,7 +361,7 @@ > .endif > .PATH.m: ${_MPATH} > .for _s in ${SRCS:M*_if.[ch]} > -.if eixsts(${_s:R}.m}) > +.if exists(${_s:R}.m}) > CLEANFILES+= ${_s} > .endif > .endfor # _s > > Make doesn’t really have the ability to cache results run-to-run, but I’ll poke at other options. In the mean time, you can do something like: > setenv _MPATH `(cd $MAKEOBJDIRPREFIX/path/sys/GENERIC; make -V _MPATH)` I'll pass it on. > to cache the value. Not ideal, but likely good enough for repeated module builds. If I can’t come up with anything clever, I’ll just commit the current list… > I hate doing that, but I also hadn’t counted upon find taking so stinkin’ long... I think "find" is fine, tough maybe store the result in a file or something which is checked into the svn .... --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55B90AEA.2040806>