On Tue, Jun 16, 2026 at 03:21:58PM +1000, Gavin Shan wrote: > On 6/16/26 3:17 PM, Michael S. Tsirkin wrote: > > On Tue, Jun 16, 2026 at 02:55:52PM +1000, Gavin Shan wrote: > > > On 6/16/26 2:49 PM, Michael S. Tsirkin wrote: > > > > On Mon, Jun 15, 2026 at 09:48:00PM -0700, Richard Henderson wrote: > > > > > On 6/15/26 21:23, Michael S. Tsirkin wrote: > > > > > > B. Also on x86, I do not see why we should not use memcpy for large > > > > > > accesses if we can. Better perf. > > > > > > > > > > We have an example where memcpy writes to the same location 3 times. > > > > > This is not appropriate for any host. > > > > > > > > > > > > > > > r~ > > > > > > > > as in, same byte? could you share the details pls? > > > > > > > > > > This issue happened on aarch64 only. > > > > > > https://lore.kernel.org/qemu-devel/cafeaca8dwhv8f48kb-013rxkg9kkczhym9_qarkmoeufeh0...@mail.gmail.com/ > > > > > > Thanks, > > > Gavin > > > > oh wow. thanks for sharing! > > > > Still I think for sizes outside of 2,4,8 it's fine? > > That is where the perf is. > > > > For that point, I agree with you that it's fine to use memcpy/memmove > when the length is 16-bytes or more, > unless Richard is concerned by > this.
yea size cutoff is a heuristic but i guess it's the best we can do. or disable memcpy completely if Richard feels strongly about it. But it seems like a waste. > I'm posting (v3) and lets continue the discussion on (v3) series. Sorry > for taking your guys so many time to review and discuss ;-) > > Thanks, > Gavin > pls do include the list of issues and high level solution in the cover letter though.
