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.
next prev parent 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).