Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 153
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 5月, 2009 1 次提交
  3. 14 5月, 2009 5 次提交
  5. 09 5月, 2009 1 次提交
  7. 01 5月, 2009 3 次提交
  9. 29 4月, 2009 26 次提交
  11. 28 4月, 2009 4 次提交
    • E
      net: Avoid extra wakeups of threads blocked in wait_for_packet() · bf368e4e
      由 Eric Dumazet 提交于 
      In 2.6.25 we added UDP mem accounting.

This unfortunatly added a penalty when a frame is transmitted, since
we have at TX completion time to call sock_wfree() to perform necessary
memory accounting. This calls sock_def_write_space() and utimately
scheduler if any thread is waiting on the socket.
Thread(s) waiting for an incoming frame was scheduled, then had to sleep
again as event was meaningless.

(All threads waiting on a socket are using same sk_sleep anchor)

This adds lot of extra wakeups and increases latencies, as noted
by Christoph Lameter, and slows down softirq handler.

Reference : http://marc.info/?l=linux-netdev&m=124060437012283&w=2 

Fortunatly, Davide Libenzi recently added concept of keyed wakeups
into kernel, and particularly for sockets (see commit
37e5540b 
epoll keyed wakeups: make sockets use keyed wakeups)

Davide goal was to optimize epoll, but this new wakeup infrastructure
can help non epoll users as well, if they care to setup an appropriate
handler.

This patch introduces new DEFINE_WAIT_FUNC() helper and uses it
in wait_for_packet(), so that only relevant event can wakeup a thread
blocked in this function.

Trace of function calls from bnx2 TX completion bnx2_poll_work() is :
__kfree_skb()
 skb_release_head_state()
  sock_wfree()
   sock_def_write_space()
    __wake_up_sync_key()
     __wake_up_common()
      receiver_wake_function() : Stops here since thread is waiting for an INPUT
Reported-by: NChristoph Lameter <cl@linux.com>
Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf368e4e
    • G
      powerpc/ps3: Fix build error on UP · d8f48457
      由 Geoff Levand 提交于 
      A non-SMP version of smp_send_stop() is now included in smp.h.
Remove the unneeded definition in the PS3 smp.c.

Fixes build errors like these when CONFIG_SMP=n:

  arch/powerpc/platforms/ps3/setup.c:49: error: redefinition of 'smp_send_stop'
  include/linux/smp.h:125: error: previous definition of 'smp_send_stop' was here
Reported-by: NSubrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d8f48457
    • M
      powerpc/cell: Select PCI for IBM_CELL_BLADE AND CELLEB · ff61e5cc
      由 Michael Ellerman 提交于 
      Currently PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but does not
select PCI. This can lead to a config with the former and the latter
disabled, which does not build.

To fix this PPC_CELL_NATIVE should select PCI. However, that would
force PCI on for QPACE, which also selects PPC_CELL_NATIVE. So
instead move the select of PPC_OF_PLATFORM_PCI and PCI under both
IBM_CELL_BLADE and CELLEB.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      ff61e5cc
    • K
      powerpc: ppc32 needs elf_read_implies_exec() · 2e8aead1
      由 Kumar Gala 提交于 
      On ppc64 we implemented elf_read_implies_exec() for 32-bit binaries
because old toolchains had bugs where they didn't mark program
segments executable that needed to be.  For some reason we didn't do
this on ppc32 builds.  This hadn't been an issue until commit 8d30c14c
("powerpc/mm: Rework I$/D$ coherency (v3)"), which had as a side
effect that we are now enforcing execute permissions to some extent on
32-bit 4xx and Book E processors.

This fixes it by defining elf_read_implies_exec on 32-bit to turn on
the read-implies-exec behaviour on programs that are sufficiently old
that they don't have a PT_GNU_STACK program header.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      2e8aead1