Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 23 4月, 2011 1 次提交
  3. 20 4月, 2011 24 次提交
  5. 05 4月, 2011 1 次提交
    • L
      tty: fix endless work loop when the buffer fills up · a5660b41
      由 Linus Torvalds 提交于 
      Commit f23eb2b2 ('tty: stop using "delayed_work" in the tty layer')
ended up causing hung machines on UP with no preemption, because the
work routine to flip the buffer data to the ldisc would endlessly re-arm
itself if the destination buffer had filled up.

With the delayed work, that only caused a timer-driving polling of the
tty state every timer tick, but without the delay we just ended up with
basically a busy loop instead.

Stop the insane polling, and instead make the code that opens up the
receive room re-schedule the buffer flip work.  That's what we should
have been doing anyway.

This same "poll for tty room" issue is almost certainly also the cause
of excessive kworker activity when idle reported by Dave Jones, who also
reported "flush_to_ldisc executing 2500 times a second" back in Nov 2010:

  http://lkml.org/lkml/2010/11/30/592

which is that silly flushing done every timer tick.  Wasting both power
and CPU for no good reason.
Reported-and-tested-by: NAlexander Beregalov <a.beregalov@gmail.com>
Reported-and-tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Cc: Greg KH <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a5660b41
  7. 31 3月, 2011 4 次提交
  9. 30 3月, 2011 2 次提交
  11. 29 3月, 2011 1 次提交
  13. 26 3月, 2011 1 次提交
  15. 25 3月, 2011 1 次提交
  17. 24 3月, 2011 1 次提交
  19. 23 3月, 2011 1 次提交
    • L
      tty: stop using "delayed_work" in the tty layer · f23eb2b2
      由 Linus Torvalds 提交于 
      Using delayed-work for tty flip buffers ends up causing us to wait for
the next tick to complete some actions.  That's usually not all that
noticeable, but for certain latency-critical workloads it ends up being
totally unacceptable.

As an extreme case of this, passing a token back-and-forth over a pty
will take two ticks per iteration, so even just a thousand iterations
will take 8 seconds assuming a common 250Hz configuration.

Avoiding the whole delayed work issue brings that ping-pong test-case
down to 0.009s on my machine.

In more practical terms, this latency has been a performance problem for
things like dive computer simulators (simulating the serial interface
using the ptys) and for other environments (Alan mentions a CP/M emulator).
Reported-by: NJef Driesen <jefdriesen@telenet.be>
Acked-by: NGreg KH <gregkh@suse.de>
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f23eb2b2
  21. 16 3月, 2011 1 次提交
    • J
      drivers/serial/ucc_uart.c: Add of_node_put to avoid memory leak · 48a10cdf
      由 Julia Lawall 提交于 
      Add a call to of_node_put in the error handling code following a call to
of_find_compatible_node or of_find_node_by_type.

This patch also substantially reorganizes the error handling code in the
function, to that it is possible first to jump to code that frees qe_port
and then to jump to code that also puts np.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r exists@
local idexpression x;
expression E,E1,E2;
statement S;
@@

*x =
(of_find_node_by_path
|of_find_node_by_name
|of_find_node_by_phandle
|of_get_parent
|of_get_next_parent
|of_get_next_child
|of_find_compatible_node
|of_match_node
|of_find_node_by_type
|of_find_node_with_property
|of_find_matching_node
|of_parse_phandle
)(...);
...
if (x == NULL) S
<... when != x = E
*if (...) {
  ... when != of_node_put(x)
      when != if (...) { ... of_node_put(x); ... }
(
  return <+...x...+>;
|
*  return ...;
)
}
...>
(
E2 = x;
|
of_node_put(x);
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NTimur Tabi <timur@freescale.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      48a10cdf
  23. 15 3月, 2011 1 次提交
  25. 10 3月, 2011 1 次提交