From: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Namhyung Kim <namhyung@gmail.com>,
Kees Cook <kees.cook@canonical.com>,
James Morris <jmorris@namei.org>, Ingo Molnar <mingo@elte.hu>,
linux-arm-msm@vger.kernel.org, smuckle@codeaurora.org
Subject: release_console_sem() and disabling interrupts
Date: Wed, 22 Dec 2010 14:28:08 -0800 [thread overview]
Message-ID: <4D127B78.7060707@codeaurora.org> (raw)
release_console_sem() disables interrupts while it calls upon the
console drivers to dump the pending characters. This disabling of
interrupt is delaying the handling of interrupts leading to weird
latencies and bugs.
The specific scenario is while resuming, the __log_buf has accumulated
around 11,000 bytes of characters and resume_console takes for ever to
send them out. On my system with serial running at 115200 baud it takes
almost a second to flush 11,000 bytes.
I was thinking about limiting the characters to say N bytes and before
the next set of N bytes is sent, we enable interrupts and do the
spin_lock_irqsave again. Basically spin in the for ( ; ; ) loop until
all the outstanding bytes are sent in sets of N bytes.
This issue has been brought up many times earlier -
http://www.webservertalk.com/archive242-2006-6-1537307.html
http://www.webservertalk.com/archive242-2007-11-2129981.html
One reason I gather is that we want to prevent interrupts from printing
unorderly stuff in the __log_buf. But dont interrupts get the
spin_lock(&logbuf_lock) and then update the log_[end/start], con_start
etc? If so we wont see unorderly prints in the __log_buf, the spin_lock
protects those pointers.
Would like ask if limiting the number of characters per loop in
release_console_sem() is a good idea.
Thanks
Abhijeet
Sent by an Employee of the Qualcomm Innovation Center, Inc. The Qualcomm
Innovation Center, Inc is a member of code aurora forum.
reply other threads:[~2010-12-22 22:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4D127B78.7060707@codeaurora.org \
--to=adharmap@codeaurora.org \
--cc=akpm@linux-foundation.org \
--cc=jmorris@namei.org \
--cc=kees.cook@canonical.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@gmail.com \
--cc=smuckle@codeaurora.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).