Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Nov 2020 10:01:05 -0500
From:      Alexander Motin <mav@FreeBSD.org>
To:        Konstantin Belousov <kib@FreeBSD.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: MAXPHYS bump for FreeBSD 13
Message-ID:  <aac44f21-3a6d-c697-bb52-1a669b11aa3b@FreeBSD.org>

next in thread | raw e-mail | index | archive | help
On Fri, 13 Nov 2020 21:09:37 +0200 Konstantin Belousov wrote:
> To put the specific numbers, for struct buf it means increase by 1792
> bytes. For bio it does not, because it does not embed vm_page_t[] into
> the structure.
>
> Worse, typical struct buf addend for excess vm_page pointers is going
> to be unused, because normal size of the UFS block is 32K.  It is
> going to be only used by clusters and physbufs.
>
> So I object against bumping this value without reworking buffers
> handling of b_pages[].  Most straightforward approach is stop using
> MAXPHYS to size this array, and use external array for clusters.
> Pbufs can embed large array.

I am not very familiar with struct buf usage, so I'd appreciate some
help there.

Quickly looking on pbuf, it seems trivial to allocate external b_pages
array of any size in pbuf_init, that should easily satisfy all of pbuf
descendants.  Cluster and vnode/swap pagers code are pbuf descendants
also.  Vnode pager I guess may only need replacement for
nitems(bp->b_pages) in few places.

Could you or somebody help with vfs/ffs code, where I suppose the
smaller page lists are used?

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aac44f21-3a6d-c697-bb52-1a669b11aa3b>