On 11/30/22 20:52, David Marchand wrote:
> On Wed, Nov 30, 2022 at 8:46 PM Ilya Maximets <i.maxim...@ovn.org> wrote:
>>
>> On 11/30/22 20:11, Mike Pattrick wrote:
>>> On Wed, Nov 30, 2022 at 7:27 AM Ilya Maximets <i.maxim...@ovn.org> wrote:
>>>>
>>>> On 11/25/22 18:19, Adrian Moreno wrote:
>>>>> Hi Mike,
>>>>>
>>>>> Sorry it took that long to review this patch.
>>>>>
>>>>> On 3/25/22 23:17, Mike Pattrick wrote:
>>>>>> Add new option --dump-hugepages option in ovs-ctl to enable the addition
>>>>>> of hugepages in the core dump filter.
>>>>>>
>>>>>> Signed-off-by: Mike Pattrick <m...@redhat.com>
>>>>>> ---
>>>>>> NEWS | 4 ++++
>>>>>> utilities/ovs-ctl.in | 15 +++++++++++----
>>>>>> 2 files changed, 15 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/NEWS b/NEWS
>>>>>> index 8fa57836a..7af60dce3 100644
>>>>>> --- a/NEWS
>>>>>> +++ b/NEWS
>>>>>> @@ -3,6 +3,10 @@ Post-v2.17.0
>>>>>> - OVSDB:
>>>>>> * 'relay' service model now supports transaction history, i.e.
>>>>>> honors the
>>>>>> 'last-txn-id' field in 'monitor_cond_since' requests from
>>>>>> clients.
>>>>>> + - ovs-ctl:
>>>>>> + * New option '--dump-hugepages' to include hugepages in core
>>>>>> dumps. This
>>>>>> + can assist with postmortem analysis involving DPDK, but may also
>>>>>> produce
>>>>>> + significantly larger core dump files.
>>>>>>
>>>>>
>>>>> I'm afraid this part needs rebasing.
>>>>>
>>>>>> v2.17.0 - 17 Feb 2022
>>>>>> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
>>>>>> index e6e07f476..8f900314b 100644
>>>>>> --- a/utilities/ovs-ctl.in
>>>>>> +++ b/utilities/ovs-ctl.in
>>>>>> @@ -103,8 +103,13 @@ set_system_ids () {
>>>>>> action "Configuring Open vSwitch system IDs" "$@" $extra_ids
>>>>>> }
>>>>>> -check_force_cores () {
>>>>>> - if test X"$FORCE_COREFILES" = Xyes; then
>>>>>> +check_core_config () {
>>>>>> + if test X"$DUMP_HUGEPAGES" = Xyes; then
>>>>>> + echo 0x3f > /proc/self/coredump_filter
>>>>
>>>> Shouldn't this be 0x7f instead?
>>>> 0x3f doesn't enable bit #6, which is responsible for dumping
>>>> shared huge pages. Or am I missing something?
>>>
>>> That's a good point, the hugepage may or may not be private. I'll send
>>> in a new one.
>>
>> OK. One thing to think about though is that we'll grab
>> VM memory, I guess, in case we have vhost-user ports.
>> So, the core dump size can become insanely huge.
>>
>> The downside of not having them is inability to inspect
>> virtqueues and stuff in the dump.
>
> Did you consider madvise()?
>
> MADV_DONTDUMP (since Linux 3.4)
> Exclude from a core dump those pages in the range
> specified by addr and length. This is useful in applications that
> have large areas of memory that are known not to be useful in a core
> dump. The effect of MADV_DONT‐
> DUMP takes precedence over the bit mask that is set via
> the /proc/[pid]/coredump_filter file (see core(5)).
>
> MADV_DODUMP (since Linux 3.4)
> Undo the effect of an earlier MADV_DONTDUMP.
I don't think OVS actually knows location of particular VM memory
pages that we do not need. And dumping virtqueues and stuff is,
probably, the point of this patch (?).
vhost-user library might have a better idea on which particular parts
of the memory guest may use for virtqueues and buffers, but I'm not
100% sure.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
