In message <CAPrugNrjoYJxkYkdYikFC9eiK45ucL-bw6=zrfdmvwxze2l...@mail.gma il.com> , Matthew Macy writes: > > On Sat, Sep 8, 2018 at 11:03 Cy Schubert <cy.schub...@cschubert.com> wrote: > > > In message <e5abddc5-17f0-bf5f-753b-1edbc9356...@alvermark.net>, Jakob > > Alvermar > > k writes:
> > > > > > I will test the patch below and report back. > > > > Agreed, though IMO your workload and your environment need to be > > understood first. What concerns me about the patch is what impact will > > it have on other workloads. Not evicting data and only metadata could > > impact buildworld -DNO_CLEAN for example. I do a -DNO_CLEAN > > buildworlds, sometimes -DWORLDFAST. Adjusting vfs.zfs.arc_meta_limit to > > the same value as vfs.zfs.arc_max improved my buildworld/installworld > > performance. In addition disabling atime for the ZFS dataset containing > > /usr/obj also improved buildworld/installworld performance by reducing > > unnecessary (IMO) metadata writes. I think evicting metadata only might > > cause a new set of problems for different workloads. (Maybe this should > > be a sysctl?) > > > > Mark's suggested change would just restore the default behavior from before > balanced pruning was imported. Balanced pruning is dependent on code that > didn't exist in FreeBSD - unfortunately when I did the import I did not > pull in all the dependencies. Mid freeze, the least disruptive path is to > disable the new behavior. Post branch we can restore it as a default, > possibly contingent on the amount of memory in the system. There is > precedent for this with prefetch. Ok. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
