Date: Sat, 3 Sep 2022 03:41:06 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, Alexander Motin <mav@FreeBSD.org>, Mateusz Guzik <mjguzik@gmail.com> Subject: Re: RFC: multiple concurrent I/O ops for copy_file_range(2) Message-ID: <YQXPR01MB4150346FF77D5B73574E9444DD7D9@YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAOtMX2jm7vg_38oV36UZ3LrJy-6hCF0Utk=dGCbfdsmr7sq9gQ@mail.gmail.com> References: <YQXPR01MB41506C61D9936C01072F6373DD7D9@YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2jm7vg_38oV36UZ3LrJy-6hCF0Utk=dGCbfdsmr7sq9gQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Somers <asomers@freebsd.org> wrote:=0A= >On Fri, Sep 2, 2022 at 9:11 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:= =0A= >>=0A= >> Hi,=0A= >>=0A= >> A recent discussion involving copy_file_range(2) performance=0A= >> included a suggestion that, maybe, copying of subranges=0A= >> should be done concurrently.=0A= >>=0A= >> Although I cannot be 100% sure, I think that this would=0A= >> involve using multiple kernel threads (taskqueue or similar)=0A= >> to issue I/O operations on the file system(s) for blocks=0A= >> (of f_iosize maybe?) concurrently, to improve performance.=0A= >>=0A= >> Doing this in a system call is unusual, to say the least but, then,=0A= >> copy_file_range(2) is an unusual system call to begin with.=0A= >>=0A= >> I have not attempted to code this up as of yet.=0A= >>=0A= >> So, what do others think of this idea?=0A= >>=0A= >> rick=0A= >=0A= >I'm skeptical. Is the intention to speed up copying on file systems=0A= >that do or don't have an efficient VOP_COPY_FILE_RANGE implementation?=0A= I suppose so. In particular, when the input and output files are on=0A= different file systems, a custom VOP_COPY_FILE_RANGE() cannot be used.=0A= =0A= > For those that don't, I don't see any point in trying to beat the=0A= >speed of the old cp(1). Apart from the problems that we've seen=0A= >around hole size, does the copy_file-range-enabled cp match the older=0A= >cp's performance?=0A= =0A= Well, the discussion starts here:=0A= https://lists.freebsd.org/archives/dev-commits-src-main/2022-August/009067.= html=0A= For some reason, there seems to be missing entries. I recall replying=0A= to the one that suggested concurrent I/O operations (by mav@, I think?)=0A= that I would post here asking about it. (I've cc'd mav@, in case he wishes= =0A= to comment further.)=0A= =0A= I do agree that doing some performance evaluation of cp(1) would be=0A= useful.=0A= --> The thread seemed to suggest (I'm no ZFS guy) that mmap'd=0A= copying does not help for ZFS and that doing copy_file_range(2)=0A= for small files instead of the mmap'd copying might make sense.=0A= --> Then there was mention of having copy_file_range(2) do concurrent=0A= copying of blocks, which precipitated the email.=0A= =0A= rick=0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR01MB4150346FF77D5B73574E9444DD7D9>