[Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix

Steven Hartland killing at multiplay.co.uk
Sat Aug 23 01:37:18 UTC 2014


----- Original Message ----- 
From: "John via freebsd-fs" <freebsd-fs at freebsd.org>

> Given how long this patch has been in use with nothing but positive 
> feedback,
> and still having not been committed, one has to wonder why?
>
> Is it NIH, and something else. It least one committer commented in the 
> past
> that Karl's approach isn't how he would have done it. Is that the 
> problem?
>
> It's ridiculous we've had to keep adding this patch to keep our zfs 
> systems
> running with decent performance.
>
> Why hasn't this been committed?

I've actually been looking at this patch today in relation to my
investigation of:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191510

I would appreciate it if people could test the attached patch, which
was created against stable/10

It should achieve the same as Karl's patch as well as:
* More closely matching original Solaris logic
* Provide better control of the reclaim trigger (absolute not
  percentage based, which becomes a problem in larger memory
  machines)
* Uses direct kernel values instead of interfacing via sysctl's.
* Should fix the issue identified in #191510 as well.

Basic design is it will trigger ARC reclaim when free pages drops
below vfs.zfs.arc_free_target, which by default is 3 x that of the
VM's target free pages as exposed by vm.v_free_target (matching
Solaris).

Its really late here now and I've only just knocked it together to
test it out on our event big cache box over the weekend, so it may
be a little rough.

All feedback welcome :)

    Regards
    Steve 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arc-reclaim.patch
Type: application/octet-stream
Size: 3619 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20140823/9a75d0bf/attachment.obj>


More information about the freebsd-fs mailing list