netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Alex Vesker <valex@mellanox.com>, Andrew Lunn <andrew@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, Tariq Toukan <tariqt@mellanox.com>,
	Jiri Pirko <jiri@mellanox.com>
Subject: Re: [PATCH net-next 0/9] devlink: Add support for region access
Date: Fri, 30 Mar 2018 16:26:27 -0600	[thread overview]
Message-ID: <86ebf2c1-dcdf-bfad-f1b8-cf73acf08ddc@gmail.com> (raw)
In-Reply-To: <98477af6-b774-48bd-f663-28a7f9f554e3@mellanox.com>

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.

  reply	other threads:[~2018-03-30 22:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-29 16:07 [PATCH net-next 0/9] devlink: Add support for region access Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 1/9] devlink: Add support for creating and destroying regions Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 2/9] devlink: Add callback to query for snapshot id before snapshot create Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 3/9] devlink: Add support for creating region snapshots Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 4/9] devlink: Add support for region get command Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 5/9] devlink: Extend the support querying for region snapshot IDs Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 6/9] devlink: Add support for region snapshot delete command Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 7/9] devlink: Add support for region snapshot read command Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 8/9] net/mlx4_core: Add health buffer address capability Alex Vesker
2018-03-29 16:07 ` [PATCH net-next 9/9] net/mlx4_core: Add Crdump FW snapshot support Alex Vesker
2018-03-29 17:13 ` [PATCH net-next 0/9] devlink: Add support for region access Andrew Lunn
2018-03-29 18:59   ` Alex Vesker
2018-03-29 19:51     ` Andrew Lunn
2018-03-30  5:28       ` Alex Vesker
2018-03-30 14:34         ` Andrew Lunn
2018-03-30 16:57           ` David Ahern
2018-03-30 19:39             ` Alex Vesker
2018-03-30 22:26               ` David Ahern [this message]
2018-03-31  6:11                 ` Alex Vesker
2018-03-31 15:53                   ` Andrew Lunn
2018-03-31 17:21                     ` David Ahern
2018-04-04 11:07                       ` Alex Vesker
2018-03-30 18:07         ` David Miller
2018-03-30 10:21       ` Jiri Pirko
2018-03-30 18:07       ` David Miller
2018-03-29 18:23 ` Andrew Lunn
2018-03-30  9:51   ` Rahul Lakkireddy
2018-03-30 10:24     ` Jiri Pirko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86ebf2c1-dcdf-bfad-f1b8-cf73acf08ddc@gmail.com \
    --to=dsahern@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=tariqt@mellanox.com \
    --cc=valex@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).