On Wed, Sep 26, 2018 at 06:43:42PM +0300, Jan Dakinevich wrote: > On Wed, 19 Sep 2018 00:23:51 +0300 > Leon Romanovsky <leon@xxxxxxxxxx> wrote: > > > On Tue, Sep 18, 2018 at 08:46:23AM -0600, Jason Gunthorpe wrote: > > > On Tue, Sep 18, 2018 at 04:03:42PM +0300, Jan Dakinevich wrote: > > > > The size of mlx4_ib_device became too large to be allocated as > > > > whole contigous block of memory. Currently it takes about 55K. On > > > > architecture with 4K page it means 3rd order. > > > > > > > > This patch series makes an attempt to split mlx4_ib_device into > > > > several parts and allocate them with less expensive kvzalloc > > > > > > Why split it up? Any reason not to just allocate the whole thing > > > with kvzalloc? > > > > This allocation could be triggered by userspace. It means that at > _arbitrary_ time kernel could be asked for high order allocation. > > This case is considered unacceptable for system under significant load, > since kernel would try to satisfy this memory request wasting the > overall performance. In such case, you won't do very much with mlx4_ib device. It will be unusable. > > > And before we are rushing to dissect mlx4_ib driver, can you > > explain the rationale behind this change? The mlx4_ib driver > > represents high-performance device which needs enough memory > > resources to operate. Those devices are limited by number > > of PCIs and SRIOV VFs (upto 126) and very rare allocated/deallocated. > > > > I would like to see real rationale behind such change. > > > > Thanks > > > > > > > > Jason > > > > -- > Best regards > Jan Dakinevich
Attachment:
signature.asc
Description: PGP signature
