From: Andrew Morton <andrewm@uow.edu.au>
To: Cort Dougan <cort@fsmlabs.com>
Cc: linux-fbdev-devel@sourceforge.net,
lkml <linux-kernel@vger.kernel.org>,
lad <linux-audio-dev@ginette.musique.umontreal.ca>,
James Simmons <jsimmons@linux-fbdev.org>,
Brad Douglas <brad@neruo.com>
Subject: Re: [prepatches] removal of console_lock
Date: Tue, 06 Mar 2001 00:00:53 +1100 [thread overview]
Message-ID: <3AA38E05.549BCF95@uow.edu.au> (raw)
In-Reply-To: <3AA1EF6C.A9C7613E@uow.edu.au>, <3AA1EF6C.A9C7613E@uow.edu.au>; from andrewm@uow.edu.au on Sun, Mar 04, 2001 at 06:31:56PM +1100 <20010304231508.M2565@ftsoj.fsmlabs.com>
Cort Dougan wrote:
>
> I still get huge over-runs with fbdev (much improved, though).
If you're referring to scheduling overruns then yes, you will
still see monstrous ones. We're still spending great lengths of
time in the kernel, only now we're doing it with interrupts
enabled. We can still block all tasks for half a second at a time.
This means that if you're telnetting into a machine and someone
cats a big file on the console, the system is completely unusable
until the `cat' completes.
(edit, edit, test, test)
OK, fixed.
> Andrew, are you still working on it? If so, I'm happy to keep you
> up-to-date on performance WRT Linux/PPC.
Please do.
I don't view this work as part of low-latency, BTW. Low
latency is a feature. The interrupt and scheduling
latencies caused by console+fbcon is a bug.
There are new patches at
http://www.uow.edu.au/~andrewm/linux/console.html
- Fixed a compile warning in i386_ksyms.c
- Include interrupt.h for UP builds
- Fixed a thinko which broke dmesg
- added console_conditional_schedule()
- used console_conditional_schedule() in four places.
This change allows the kernel to reschedule if needed while
performing lengthy console operations. Scheduling latency
is reduced from 500 milliseconds to 1 millisecond.
- Updated to latest kernels.
I think that's everything fixed. IWFM with Riva hardware. If
you still see huge latencies, please let me know how to
reproduce them - it's pretty trivial to fix it with the
new infrastructure.
BTW: the latest lolat patch still applies to 2.4.3-pre2.
People are after me for -ac patches as well, so I'll start
tracking Alan's kernels soon.
BTW2: testing methodology:
- Load netdriver with `debug=7'
- cat many files on VC1
- cat many files on VC2
- run netperf on VC3 to generate vast amounts of console and
log output in both process and interrupt context
- Madly flick between VCs
-
next prev parent reply other threads:[~2001-03-05 13:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-04 7:31 Andrew Morton
2001-03-04 10:26 ` Pierre Rousselet
2001-03-04 10:42 ` Andrew Morton
2001-03-05 6:15 ` Cort Dougan
2001-03-05 13:00 ` Andrew Morton [this message]
2001-03-05 14:36 ` Benjamin Herrenschmidt
2001-03-04 10:57 Manfred Spraul
2001-03-04 11:19 ` Andrew Morton
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=3AA38E05.549BCF95@uow.edu.au \
--to=andrewm@uow.edu.au \
--cc=brad@neruo.com \
--cc=cort@fsmlabs.com \
--cc=jsimmons@linux-fbdev.org \
--cc=linux-audio-dev@ginette.musique.umontreal.ca \
--cc=linux-fbdev-devel@sourceforge.net \
--cc=linux-kernel@vger.kernel.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®