Date: Tue, 05 Jul 2016 10:43:00 -0700 From: Matthew Macy <mmacy@nextbsd.org> To: "Freddie Cash" <fjwcash@gmail.com> Cc: "FreeBSD Hackers" <freebsd-hackers@freebsd.org>, "Karl Denninger" <karl@denninger.net> Subject: Re: ZFS ARC and mmap/page cache coherency question Message-ID: <155bc27ea44.c75d1029200540.4499688981397092064@nextbsd.org> In-Reply-To: <CAOjFWZ6qrE_JZUiXAojU3vOGmKHZB_kq7VAR4EhkkX2u2NSUHA@mail.gmail.com> References: <20160630140625.3b4aece3@splash.akips.com> <CALXu0UfxRMnaamh%2Bpo5zp=iXdNUNuyj%2B7e_N1z8j46MtJmvyVA@mail.gmail.com> <20160703123004.74a7385a@splash.akips.com> <155afb8148f.c6f5294d33485.2952538647262141073@nextbsd.org> <45865ae6-18c9-ce9a-4a1e-6b2a8e44a8b2@denninger.net> <155b84da0aa.ad3af0e6139335.8627172617037605875@nextbsd.org> <7e00af5a-86cd-25f8-a4c6-2d946b507409@denninger.net> <155bc1260e6.12001bf18198857.6272515207330027022@nextbsd.org> <CAOjFWZ6qrE_JZUiXAojU3vOGmKHZB_kq7VAR4EhkkX2u2NSUHA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
---- On Tue, 05 Jul 2016 10:35:12 -0700 Freddie Cash <fjwcash@gmail.com> w= rote ----=20 > On Tue, Jul 5, 2016 at 10:19 AM, Matthew Macy <mmacy@nextbsd.org> wrote: >=20 > > ---- On Mon, 04 Jul 2016 19:26:06 -0700 Karl Denninger < > > karl@denninger.net> wrote ---- > > > On 7/4/2016 18:45, Matthew Macy wrote: > > > > ---- On Sun, 03 Jul 2016 08:43:19 -0700 Karl Denninger < > > karl@denninger.net> wrote ---- > > > > > > > > > > On 7/3/2016 02:45, Matthew Macy wrote: > > > > > > > > > > > > Cedric greatly overstates the intractability of > > resolving it. Nonetheless, since the initial import very little has be= en > > done to improve integration, and I don't know of anyone who is up to t= he > > task taking an interest in it. Consequently, mmap() performance is lik= ely > > "doomed" for the foreseeable future.-M---- > > > > > > > > > > Wellllll.... > > > > > > > > > > I've done a fair bit of work here (see > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594) an= d the > > > > > political issues are at least as bad as the coding ones. > > > > > > > > Strictly speaking, the root of the problem is the ARC. Not ZFS pe= r > > se. Have you ever tried disabling MFU caching to see how much worse LR= U > > only is? I'm not really convinced the ARC's benefits justify its cost. > > > > > > The ARC is very useful when it gets a hit as it avoid an I/O that w= ould > > > otherwise take place. > > > > > > Where it sucks is when the system evicts working set to preserve AR= C. > > > That's always wrong in that you're trading a speculative I/O (if th= e > > > cache is hit later) for a *guaranteed* one (to page out) and maybe = *two* > > > (to page back in.) > > > > The question wasn't ARC vs. no-caching. It was LRU only vs LRU + MFU. > > There are a lot of issues stemming from the fact that ZFS is a > > transactional object store with a POSIX FS on top. One is that it cach= es > > disk blocks as opposed to file blocks. However, if one could resolve t= hat > > and have the page cache manage these blocks life would be much much be= tter. > > However, you'd lose MFU. Hence my question. > > >=20 > =E2=80=8BAre you confusing terms here? >=20 > Pretty sure the ARC uses MRU (Most Recently Used) and MFU (Most Frequent= ly > Used) caches. Not LRU (Least Recently Used). >=20 > Or am I misunderstanding what you're trying to say? =20 If it caches based on MRU, by definition it evicts LRU. I did mix caching p= olicy with eviction policy in the same sentence which is obviously not corr= ect. Nonetheless, it should be obvious that I meant MFU+MRU caching vs MRU = caching only. Thanks. -M
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?155bc27ea44.c75d1029200540.4499688981397092064>