This patch has the VT subsystem use tty_schedule_flip instead of
con_schedule_flip. There are two ways we can approach this. We can
do the below path or extend tty_schedule_flip to accept a time field.
Comments welcomed.
Signed-Off: James Simmons <[email protected]>
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index cb8d691..2db8973 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -303,7 +303,7 @@ static void put_queue(struct vc_data *vc, int ch)
if (tty) {
tty_insert_flip_char(tty, ch, 0);
- con_schedule_flip(tty);
+ tty_schedule_flip(tty);
}
}
@@ -318,7 +318,7 @@ static void puts_queue(struct vc_data *vc, char *cp)
tty_insert_flip_char(tty, *cp, 0);
cp++;
}
- con_schedule_flip(tty);
+ tty_schedule_flip(tty);
}
static void applkey(struct vc_data *vc, int key, char mode)
@@ -549,7 +549,7 @@ static void fn_send_intr(struct vc_data *vc)
if (!tty)
return;
tty_insert_flip_char(tty, 0, TTY_BREAK);
- con_schedule_flip(tty);
+ tty_schedule_flip(tty);
}
static void fn_scroll_forw(struct vc_data *vc)
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 1bbb45b..c9bbb14 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -1240,7 +1240,7 @@ static void respond_string(const char *p, struct tty_struct *tty)
tty_insert_flip_char(tty, *p, 0);
p++;
}
- con_schedule_flip(tty);
+ tty_schedule_flip(tty);
}
static void cursor_report(struct vc_data *vc, struct tty_struct *tty)
diff --git a/include/linux/kbd_kern.h b/include/linux/kbd_kern.h
index 506ad20..7b24a0d 100644
--- a/include/linux/kbd_kern.h
+++ b/include/linux/kbd_kern.h
@@ -149,16 +149,4 @@ void compute_shiftstate(void);
extern unsigned int keymap_count;
-/* console.c */
-
-static inline void con_schedule_flip(struct tty_struct *t)
-{
- unsigned long flags;
- spin_lock_irqsave(&t->buf.lock, flags);
- if (t->buf.tail != NULL)
- t->buf.tail->commit = t->buf.tail->used;
- spin_unlock_irqrestore(&t->buf.lock, flags);
- schedule_delayed_work(&t->buf.work, 0);
-}
-
#endif
On Tue, 2007-05-08 at 21:10 +0100, James Simmons wrote:
>
> This patch has the VT subsystem use tty_schedule_flip instead of
> con_schedule_flip. There are two ways we can approach this. We can
> do the below path or extend tty_schedule_flip to accept a time field.
> Comments welcomed.
This looks reasonable.
I don't think a time field is necessary. In fact, I think the
scheduled_delayed_work() in tty_schedule_flip() should use a
time of 0 just like con_schedule_flip().
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.
It would be better for performance to process the receive data
as soon as possible (delay value of 0).
--
Paul Fulghum
Microgate Systems, Ltd
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.
> 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.
Great!!!! Here is the patch updated with the delay value set to zero.
Signed-Off: James Simmons <[email protected]>
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 1b09450..0027736 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -277,7 +277,7 @@ static void put_queue(struct vc_data *vc, int ch)
if (tty) {
tty_insert_flip_char(tty, ch, 0);
- con_schedule_flip(tty);
+ tty_schedule_flip(tty);
}
}
@@ -292,7 +292,7 @@ static void puts_queue(struct vc_data *vc, char *cp)
tty_insert_flip_char(tty, *cp, 0);
cp++;
}
- con_schedule_flip(tty);
+ tty_schedule_flip(tty);
}
static void applkey(struct vc_data *vc, int key, char mode)
@@ -523,7 +523,7 @@ static void fn_send_intr(struct vc_data *vc)
if (!tty)
return;
tty_insert_flip_char(tty, 0, TTY_BREAK);
- con_schedule_flip(tty);
+ tty_schedule_flip(tty);
}
static void fn_scroll_forw(struct vc_data *vc)
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index 7710a6a..0174c3f 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -530,7 +530,7 @@ void tty_schedule_flip(struct tty_struct *tty)
if (tty->buf.tail != NULL)
tty->buf.tail->commit = tty->buf.tail->used;
spin_unlock_irqrestore(&tty->buf.lock, flags);
- schedule_delayed_work(&tty->buf.work, 1);
+ schedule_delayed_work(&tty->buf.work, 0);
}
EXPORT_SYMBOL(tty_schedule_flip);
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index bbd9fc4..283e189 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -1261,7 +1261,7 @@ static void respond_string(const char *p, struct tty_struct *tty)
tty_insert_flip_char(tty, *p, 0);
p++;
}
- con_schedule_flip(tty);
+ tty_schedule_flip(tty);
}
static void cursor_report(struct vc_data *vc, struct tty_struct *tty)
diff --git a/include/linux/kbd_kern.h b/include/linux/kbd_kern.h
index 506ad20..7b24a0d 100644
--- a/include/linux/kbd_kern.h
+++ b/include/linux/kbd_kern.h
@@ -149,16 +149,4 @@ void compute_shiftstate(void);
extern unsigned int keymap_count;
-/* console.c */
-
-static inline void con_schedule_flip(struct tty_struct *t)
-{
- unsigned long flags;
- spin_lock_irqsave(&t->buf.lock, flags);
- if (t->buf.tail != NULL)
- t->buf.tail->commit = t->buf.tail->used;
- spin_unlock_irqrestore(&t->buf.lock, flags);
- schedule_delayed_work(&t->buf.work, 0);
-}
-
#endif
James Simmons wrote:
> Great!!!! Here is the patch updated with the delay value set to zero.
Acked-by: Paul Fulghum <[email protected]>
You should submit this to
Andrew Morton <[email protected]>
so it can get into the mm tree.
--
Paul