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...

Hans Petter Selasky hps at selasky.org
Wed Jul 29 17:17:10 UTC 2015


On 07/29/15 18:59, Warner Losh wrote:
>
>> On Jul 29, 2015, at 9:46 AM, Hans Petter Selasky <hps at selasky.org> wrote:
>>
>> On 07/29/15 16:24, Warner Losh wrote:
>>>
>>>> On Jul 29, 2015, at 4:19 AM, Hans Petter Selasky <hps at selasky.org> wrote:
>>>>
>>>> On 07/03/15 22:15, Warner Losh wrote:
>>>>>
>>>>>> On Jul 3, 2015, at 11:35 AM, Roger Pau Monné <royger at 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



More information about the svn-src-head mailing list