From: Paul Fulghum <paulkf@microgate.com>
To: James Simmons <jsimmons@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux console project <linuxconsole-dev@lists.sourceforge.net>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] Use tty_schedule in VT code.
Date: Wed, 09 May 2007 14:58:28 -0600 [thread overview]
Message-ID: <464235F4.6080006@microgate.com> (raw)
In-Reply-To: <1178656361.14867.7.camel@x2.microgate.com>
Paul Fulghum wrote:
> As the tty flip buffer code has evolved, that delay value of 1
> was carried along. It may have had some historical purpose, but
> I can't figure it out and it appears to have no use currently.
I looked further back and in the 2.4 kernels this scheduling
was done with the timer task queue (process receive data on
next timer tick).
I guess the schedule_delayed_work() with a time delay of 1
was the best approximation of the previous behavior.
There is no logical reason to delay the first attempt at
processing receive data so schedule_delayed_work() in
tty_schedule_flip() should be changed to 0 (as was the
case for con_schedule_flip).
The schedule_delayed_work in flush_to_ldisc() will continue
to use a delay of 1 if the ldisc can't accept more data.
This allows the user app and ldisc to catch up.
Subsequent calls to tty_schedule_flip won't affect
this 'back off' delay because once the work is scheduled
(with a delay of 1) new scheduling calls are ignored for
the same work structure.
I've been testing the change to 0 in tty_schedule_flip()
under various loads and data rates with no ill effects.
--
Paul Fulghum
Microgate Systems, Ltd.
next prev parent reply other threads:[~2007-05-09 19:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-08 20:10 [PATCH] Use tty_schedule in VT code James Simmons
2007-05-08 20:32 ` Paul Fulghum
2007-05-09 20:58 ` Paul Fulghum [this message]
2007-05-09 20:56 ` James Simmons
2007-05-09 23:02 ` Paul Fulghum
-- strict thread matches above, loose matches on Subject: below --
2007-07-17 18:37 James Simmons
2007-07-17 18:49 ` Samuel Thibault
2007-07-17 19:17 ` James Simmons
2007-07-17 20:31 ` Paul Fulghum
2007-07-17 19:24 ` Linus Torvalds
2007-07-17 20:35 ` Paul Fulghum
2007-07-17 19:44 ` Linus Torvalds
2007-07-17 19:52 ` James Simmons
2007-07-17 20:42 ` Linus Torvalds
2007-07-17 23:35 ` Alan Cox
2007-07-18 18:17 ` James Simmons
2007-07-18 18:27 ` Paul Fulghum
2007-07-18 19:57 ` James Simmons
2007-07-18 21:12 ` Paul Fulghum
2007-07-18 20:08 ` Linus Torvalds
2007-07-18 21:36 ` Alan Cox
2007-07-17 21:06 ` Paul Fulghum
2007-07-17 20:15 ` James Simmons
2007-07-17 21:33 ` Paul Fulghum
2007-07-18 17:19 ` James Simmons
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=464235F4.6080006@microgate.com \
--to=paulkf@microgate.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jsimmons@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxconsole-dev@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.