> On Apr 4, 2015, at 9:08 AM, Matthew Ahrens wrote:
>
> Strided prefetch: mostly evil.
Agree, we’ve routinely disabled on many workloads, especially virtualization
workloads with many VMs.
At the very least you can measure the effectiveness and determine whether
prefetching is really helping
On 04.04.2015 21:36, Matthew Ahrens wrote:
> On Sat, Apr 4, 2015 at 11:18 AM, Alexander Motin PS: FreeBSD code style does not recommend inline definition of
> variables, that you used several times in your patch.
>
> No C99 in FreeBSD? I didn't realize that illumos was the only operating
On Sat, Apr 4, 2015 at 11:18 AM, Alexander Motin wrote:
> On 04.04.2015 19:08, Matthew Ahrens wrote:
> > Strided prefetch: mostly evil.
> >
> > I've rewritten the predictive prefetcher; new version only detects
> > forward sequential streams. Will propose for upstreaming soon. In the
> > mean t
On 04.04.2015 19:08, Matthew Ahrens wrote:
> Strided prefetch: mostly evil.
>
> I've rewritten the predictive prefetcher; new version only detects
> forward sequential streams. Will propose for upstreaming soon. In the
> mean time feel free to check out:
>
> https://github.com/delphix/delphix-o
Strided prefetch: mostly evil.
I've rewritten the predictive prefetcher; new version only detects forward
sequential streams. Will propose for upstreaming soon. In the mean time
feel free to check out:
https://github.com/delphix/delphix-os/commit/13cf8efe4b6b10930b478a15f9de92880bbdd412
--matt
Hi.
Experimenting with SPEC NFS benchmark I've noticed significant amount of
CPU time, spent by ZFS prefetcher code. The most interesting is that
time was spent when prefercher was called not for data access, but by
dnode_hold()->dbuf_read() when accessing blocks of DMU_META_DNODE(os).
Further inv
