linux-kernel - Re: [PATCH 0/4] IB: decrease large contigous allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180926184342.44deaa4f@virtuozzo.com>
Date:   Wed, 26 Sep 2018 18:43:42 +0300
From:   Jan Dakinevich <jan.dakinevich@...tuozzo.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Jason Gunthorpe <jgg@...pe.ca>, Doug Ledford <dledford@...hat.com>,
        Yishai Hadas <yishaih@...lanox.com>,
        Parav Pandit <parav@...lanox.com>,
        Mark Bloch <markb@...lanox.com>,
        Daniel Jurgens <danielj@...lanox.com>,
        Kees Cook <keescook@...omium.org>,
        Kamal Heib <kamalheib1@...il.com>,
        Bart Van Assche <bvanassche@....org>,
        linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
        Denis Lunev <den@...tuozzo.com>,
        Konstantin Khorenko <khorenko@...tuozzo.com>
Subject: Re: [PATCH 0/4] IB: decrease large contigous allocation

On Wed, 19 Sep 2018 00:23:51 +0300
Leon Romanovsky <leon@...nel.org> 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.

> 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