From: Daniel Bristot de Oliveira <bristot@redhat.com>
To: Paul Gortmaker <paul.gortmaker@windriver.com>,
linux-rt-users@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH RT] netconsole: enable netconsole on PREEMPT_RT
Date: Mon, 05 May 2014 16:10:51 -0300 [thread overview]
Message-ID: <5367E23B.7060908@redhat.com> (raw)
In-Reply-To: <536256EC.1060909@windriver.com>
On 05/01/2014 11:15 AM, Paul Gortmaker wrote:
> Chances are the two real targets above were using the
> same igb network driver. I wonder if it matters what
> underlying nic is used for netconsole?
These three machines are using different drivers:
+----------+------------+
| Machine | Nic Module |
+----------+------------+
| Xeon | tg3 |
| core i5 | r8169 |
| KVM VM | virtio_net |
+----------+------------+
Netconsole uses the function netpoll_send_udp to send a packet,
and netpool_send_udp calls the driver's ".ndo_start_xmit" function.
So it end up calling the NIC driver, but it's not "hardware
dependent".
> It is probably worthwhile to do some data mining into why
> it was disabled in the 1st place. I can't say I recall, and
> it is possible that the reason has long since become irrelevant,
> even though the patch has been carried forward over time.
Figure out why it was disabled is one objective of this RFC :-).
I did not found any message about some error of netconsole on RT
kernel. I enabled the netconsole waiting for some obscure bug,
but surprisingly it always worked fine.
> Or it may be that your testing simply doesn't cover the use
> case where netconsole will spew sleeping while atomic...
In order to test netconsole, I developed a (very simple) module to call
the printk using the sysfs interface [1]. This module creates a sysfs
file that calls printk passing the wrote message as the printk message.
This module runs in 4 execution modes:
[n]one: call printk
[i]rq: call printk inside an irq disabled section
[p]reempt: call printk inside a preempt disabled section
[x]: call printk alternating the above modes
I ran the tests injecting printk using this four modes, using
concurrent threads, for example one thread per core injecting printk.
The point is, when the printk is called, firstly it stores the
message in the log buffer, and then it try to grab the console lock to
print the messages to the registered consoles. To grab the console
lock, printk calls the function console_trylock_for_printk. This
function, on a kernel configured with PREEMPT_RT_FULL, will check
if the system is in atomic. If the system is in atomic, it will fail,
and printk will not call the console drivers (this test is
implemented on patch printk-rt-aware.patch). The message will be
be printed to the console after, by a kworker, calling the
netconsole on the preemptive context. This is another good thing
for the RT kernel, as it can't be called inside an atomic section,
and it didn't disables the preemption and IRQs, it does not add a
possible point of latency.
[1] http://bristot.eti.br/files/netconsole/printk_inject.tar.gz
-- Daniel Bristot
next prev parent reply other threads:[~2014-05-05 19:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 17:55 [RFC PATCH RT] netconsole: enable netconsole on PREEMPT_RT Daniel Bristot de Oliveira
2014-05-01 14:15 ` Paul Gortmaker
2014-05-05 19:10 ` Daniel Bristot de Oliveira [this message]
2014-05-09 15:55 ` Sebastian Andrzej Siewior
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=5367E23B.7060908@redhat.com \
--to=bristot@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=paul.gortmaker@windriver.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).