From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [PATCH net-next 0/9] devlink: Add support for region access Date: Fri, 30 Mar 2018 16:26:27 -0600 Message-ID: <86ebf2c1-dcdf-bfad-f1b8-cf73acf08ddc@gmail.com> References: <1522339672-18273-1-git-send-email-valex@mellanox.com> <20180329171359.GA12150@lunn.ch> <962b56c1-d471-97ec-e8e9-18252e809dfe@mellanox.com> <20180329195154.GB15565@lunn.ch> <28b99a08-1967-3044-4010-0faa5d6bfc14@mellanox.com> <20180330143403.GD28244@lunn.ch> <6d55f271-18f9-9ca5-0dbf-24951dd09978@gmail.com> <98477af6-b774-48bd-f663-28a7f9f554e3@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "David S. Miller" , netdev@vger.kernel.org, Tariq Toukan , Jiri Pirko To: Alex Vesker , Andrew Lunn Return-path: Received: from mail-pf0-f193.google.com ([209.85.192.193]:39896 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752525AbeC3W0a (ORCPT ); Fri, 30 Mar 2018 18:26:30 -0400 Received: by mail-pf0-f193.google.com with SMTP id c78so6182360pfj.6 for ; Fri, 30 Mar 2018 15:26:30 -0700 (PDT) In-Reply-To: <98477af6-b774-48bd-f663-28a7f9f554e3@mellanox.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 3/30/18 1:39 PM, Alex Vesker wrote: > > > On 3/30/2018 7:57 PM, David Ahern wrote: >> On 3/30/18 8:34 AM, Andrew Lunn wrote: >>>>> And it seems to want contiguous pages. How well does that work after >>>>> the system has been running for a while and memory is fragmented? >>>> The allocation can be changed, there is no read need for contiguous >>>> pages. >>>> It is important to note that we the amount of snapshots is limited >>>> by the >>>> driver >>>> this can be based on the dump size or expected frequency of collection. >>>> I also prefer not to pre-allocate this memory. >>> The driver code also asks for a 1MB contiguous chunk of memory!  You >>> really should think about this API, how can you avoid double memory >>> allocations. And can kvmalloc be used. But then you get into the >>> problem for DMA'ing the memory from the device... >>> >>> This API also does not scale. 1MB is actually quite small. I'm sure >>> there is firmware running on CPUs with a lot more than 1MB of RAM. >>> How well does with API work with 64MB? Say i wanted to snapshot my >>> GPU? Or the MC/BMC? >>> >> That and the drivers control the number of snapshots. The user should be >> able to control the number of snapshots, and an option to remove all >> snapshots to free up that memory. > > There is an option to free up this memory, using a delete command. > The reason I added the option to control the number of snapshots from > the driver side only is because the driver knows the size of the snapshots > and when/why they will be taken. > For example in our mlx4 driver the snapshots are taken on rare failures, > the snapshot is quite large and from past analyses the first dump is > usually > the important one, this means that 8 is more than enough in my case. > If a user wants more than that he can always monitor notification read > the snapshot and delete once backup-ed, there is no reason for keeping > all of this data in the kernel. > > I was thinking less. ie., a user says keep only 1 or 2 snapshots or disable snapshots altogether.