zio unused UMA zones

[Pawel Jakub Dawidek]

On Mon, Apr 29, 2013 at 07:56:15PM +0200, Davide Italiano wrote:
> On Sat, Apr 20, 2013 at 11:07 PM, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
> > On Fri, Apr 19, 2013 at 01:22:57PM +0200, Davide Italiano wrote:
> >> Hi.
> >> Looking at vmstat -z I saw zones zio_buf and zio_data_buf are created
> >> even if vfs.zfs.zio.use_uma is set to zero.
> >> If UMA is not used for allocating ZFS I/O buffers such zones remain
> >> unused. Is there any reason to create them I'm missing or is this just
> >> an oversight?
> >> In case it's the second choice, do you mind if I modify the code so
> >> that zones are created only if needed?
> >
> > The only reason I can think of to leave those zone around is ability to
> > switch between UMA-allocated buffers and malloc-allocated buffers at
> > runtime, but currently I don't think this is possible (we would be able
> > to tell how the given buffer was allocated), so most likely I first
> > implemented this by using UMA, but when problems with KVA fragmentation
> > appeared I added a switch to use malloc and haven't made UMA zones
> > creations to depend on this switch.
> >
> > I'd be happy to review the patch.
> >
> > --
> > Pawel Jakub Dawidek                       http://www.wheelsystems.com
> > FreeBSD committer                         http://www.FreeBSD.org
> > Am I Evil? Yes, I Am!                     http://mobter.com
> 
> This should suffice, I guess
> 
> http://people.freebsd.org/~davide/review/zfs_noumacreate.diff

I wouldn't skip zfs_mg_alloc_failures initialization, so if you move the
'out' label above that, I'm fine with the patch.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/zfs-devel/attachments/20130429/da7ae252/attachment.sig>