DPDK patches and discussions
 help / color / mirror / Atom feed
From: Lewis Donzis <lew@perftech.com>
To: dev@dpdk.org
Subject: [dpdk-dev] CPU hog & memory leak on FreeBSD
Date: Mon, 3 Aug 2020 14:43:05 -0500 (CDT)	[thread overview]
Message-ID: <1748858460.2301535.1596483785377.JavaMail.zimbra@donzis.com> (raw)

Hello. 

We've posted about this before, but I'm hoping to find someone willing to commit a patched version of lib/librte_eal/bsdapp/eal/eal_interrupts.c that corrects a memory leak and 100% CPU hog that is immediately noticeable with the i40e driver, at a minimum. We have modified this file to correct the problem, and would be happy to provide it back to whomever is a committer for this. 

The detailed explanation is: 

Currently, s etting an alarm with rte_eal_alarm_set() registers an alarm interrupt by calling rte_intr_callback_register(), which links the callback function (eal_alarm_callback) onto a list for that source and sets up a one-shot timer via kevent. Setting additional alarms links them on to the alarm_list, but also calls rte_eal_alarm_set() again, which links the callback function onto the source callback list again. 

When the alarm triggers and eal_alarm_callback() gets called, it goes down the list of pending alarms, calling as many callback functions as possible and removing each one from the list until it reaches one which has not yet expired. Once it's done, if alarm_list is not empty, it calls rte_intr_callback_register(), which then links yet another callback onto the interrupt source's list, thus creating an infinite loop. 

The problem is that the source callback list grows infinitely under this condition (essentially, when more than one alarm is queued). However, the call is necessary in order to reset the kevent timer. 

The proposed fix recognizes and leverages the fact that an alarm interrupt in FreeBSD should never have more than one callback on its list, so if rte_intr_callback_register() is called with an interrupt handle type of RTE_INTR_HANDLE_ALARM, and if such an interrupt type already has a non-empty list, then a new callback is not created, but the kevent timer is restarted properly. 

A much simpler change is possible if we don't mind the overhead of allocating, filling-in, linking, de-linking, and freeing a callback unnecessarily. This proposed change makes every attempt to avoid that overhead. 


             reply	other threads:[~2020-08-03 19:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 19:43 Lewis Donzis [this message]
2020-08-03 23:22 ` Honnappa Nagarahalli
2020-08-03 23:51   ` Lewis Donzis

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=1748858460.2301535.1596483785377.JavaMail.zimbra@donzis.com \
    --to=lew@perftech.com \
    --cc=dev@dpdk.org \
    /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).