From: Steven Rostedt <rostedt@goodmis.org>
To: kus Kusche Klaus <kus@keba.com>
Cc: Linus Torvalds <torvalds@osdl.org>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: RE: Why yield in coredump_wait? [was: Re: Resent: BUG in RT 45-01 whenRT program dumps core]
Date: Thu, 19 May 2005 10:37:07 -0400 [thread overview]
Message-ID: <1116513427.15866.52.camel@localhost.localdomain> (raw)
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323213@MAILIT.keba.co.at>
On Thu, 2005-05-19 at 16:23 +0200, kus Kusche Klaus wrote:
> Does that mean that the core dump is written
> with the rt prio of the task which dumps?
>
Yes, since the process itself that crashed is what is writing the core.
So if a RT process crashes, it writes the core as whatever it was.
> I'm not sure if this is a good idea:
> Dumping a big core might take *ages* (at least w.r.t. realtime),
> especially because it usually goes to flash memory, a CF card,
> or some other really slow device.
>
This is interesting, since if a RT task is dumping core, that usually
means that it crashed, and therefore there's a bug in the system. Also,
unless the processes is writing to something that requires a busy wait
(which the serial might do, and probably some flashes), this shouldn't
effect the system.
> Doing that on a high rt prio is not nice; in an rt kernel,
> it may even keep interrupt handlers from responding...
> Is there any way to do it in the background / at low prio?
>
What can easily be done is switch the task to a non RT priority on the
core dump, after it sends the kill signal to the other tasks sharing the
mm. This way it would not affect the other tasks (and interrupt threads)
so badly.
Ingo, What do you think? Should the dumping of a RT task switch its
priority to a non-rt priority?
-- Steve
next prev parent reply other threads:[~2005-05-19 14:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-19 14:23 kus Kusche Klaus
2005-05-19 14:37 ` Steven Rostedt [this message]
2005-05-19 16:13 ` Lee Revell
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=1116513427.15866.52.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=kus@keba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@osdl.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
all inboxes | Powered by JetHome®