Date: Sat, 23 Dec 2023 12:11:40 -0800 From: Mark Millard <marklmi@yahoo.com> To: void@f-m.fm, freebsd-fs@freebsd.org Subject: Re: measuring swap partition speed Message-ID: <8DD13AF2-C4E3-470E-B748-92828FC20D17@yahoo.com> References: <8DD13AF2-C4E3-470E-B748-92828FC20D17.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
void <void_at_f-m.fm> wrote on Date: Sat, 23 Dec 2023 15:59:21 UTC : > On Thu, 21 Dec 2023, at 17:32, Mark Millard wrote: > > [For this message I'm replying to just the one point because I > > expect that it is rather important to your context.] >=20 > > swapfile write requires the write request to come through the = filesystem > > write path, which might require the filesystem to allocate more = memory > > and read some data. E.g. it is known that any ZFS write request > > allocates memory, and that write request on large UFS file might = require > > allocating and reading an indirect block buffer to find the block = number > > of the written block, if the indirect block was not yet read. >=20 > Are nfs writes the same as a "write request through the filesystem = write path" ? > If not the same, then the same deleterious effect in the context? I expect that NFS would have the issue: SOMETHING(s) might require NFS to allocate more memory during the = attempt to do a paging I/O of interest But I'm no NFS expert. Basically, any additional layers that create additional memory allocations in managing the paging I/O contribute to such issues. The more allocations in trying to do the paging I/O, the worse the issue. Even just the fact that umass is involved for the USB I/O contributes some risk, if I understand right. (Seems to be rather low risk of itself.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8DD13AF2-C4E3-470E-B748-92828FC20D17>