All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Vesker <valex@mellanox.com>
To: David Ahern <dsahern@gmail.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 22:39:00 +0300	[thread overview]
Message-ID: <98477af6-b774-48bd-f663-28a7f9f554e3@mellanox.com> (raw)
In-Reply-To: <6d55f271-18f9-9ca5-0dbf-24951dd09978@gmail.com>



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.

  reply	other threads:[~2018-03-30 19:39 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 [this message]
2018-03-30 22:26               ` David Ahern
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=98477af6-b774-48bd-f663-28a7f9f554e3@mellanox.com \
    --to=valex@mellanox.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=tariqt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.