Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jul 2020 10:31:34 +0200
From:      Mateusz Guzik <mjguzik@gmail.com>
To:        "Piotr P. Stefaniak" <pstef@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r363068 - head/sys/kern
Message-ID:  <CAGudoHFCsJ4PUuM0Xixdf9haCObWz8wdDzx48BEoqJ7=%2B5u7QA@mail.gmail.com>
In-Reply-To: <20200710082549.GC74062@freefall.freebsd.org>
References:  <202007100646.06A6kgnX015296@repo.freebsd.org> <20200710082549.GC74062@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 7/10/20, Piotr P. Stefaniak <pstef@freebsd.org> wrote:
>> 	 */
>>-	memcpy(sbp, &mp->mnt_stat, sizeof(*sbp));
>>+	if (sbp != &mp->mnt_stat)
>>+		memcpy(sbp, &mp->mnt_stat, sizeof(*sbp));
>>
>
> Slightly unrelated question: wouldn't it be prudent to incorporate this
> logic into memcpy?
>

Calls like that are just abusing the routine and indicate design
problems in the consumer.
Adding the branch into the routine would add overhead for everyone.

However, now that you mention it, it may be prudent to do something like this:

dtrace -n 'fbt::memcpy:entry,fbt::memmove:entry /arg1 == arg2/ {
@[stack()] = count(); }'

and run your favourite workload.

-- 
Mateusz Guzik <mjguzik gmail.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHFCsJ4PUuM0Xixdf9haCObWz8wdDzx48BEoqJ7=%2B5u7QA>