1. 10 9月, 2011 1 次提交
  2. 02 9月, 2011 2 次提交
  3. 01 9月, 2011 1 次提交
    • D
      xen: use maximum reservation to limit amount of usable RAM · d312ae87
      David Vrabel 提交于
      Use the domain's maximum reservation to limit the amount of extra RAM
      for the memory balloon. This reduces the size of the pages tables and
      the amount of reserved low memory (which defaults to about 1/32 of the
      total RAM).
      
      On a system with 8 GiB of RAM with the domain limited to 1 GiB the
      kernel reports:
      
      Before:
      
      Memory: 627792k/4472000k available
      
      After:
      
      Memory: 549740k/11132224k available
      
      A increase of about 76 MiB (~1.5% of the unused 7 GiB).  The reserved
      low memory is also reduced from 253 MiB to 32 MiB.  The total
      additional usable RAM is 329 MiB.
      
      For dom0, this requires at patch to Xen ('x86: use 'dom0_mem' to limit
      the number of pages for dom0') (c/s 23790)
      
      CC: stable@kernel.org
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      d312ae87
  4. 31 8月, 2011 1 次提交
    • A
      x86, perf: Check that current->mm is alive before getting user callchain · 20afc60f
      Andrey Vagin 提交于
      An event may occur when an mm is already released.
      
      I added an event in dequeue_entity() and caught a panic with
      the following backtrace:
      
      [  434.421110] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      [  434.421258] IP: [<ffffffff810464ac>] __get_user_pages_fast+0x9c/0x120
      ...
      [  434.421258] Call Trace:
      [  434.421258]  [<ffffffff8101ae81>] copy_from_user_nmi+0x51/0xf0
      [  434.421258]  [<ffffffff8109a0d5>] ? sched_clock_local+0x25/0x90
      [  434.421258]  [<ffffffff8101b048>] perf_callchain_user+0x128/0x170
      [  434.421258]  [<ffffffff811154cd>] ? __perf_event_header__init_id+0xed/0x100
      [  434.421258]  [<ffffffff81116690>] perf_prepare_sample+0x200/0x280
      [  434.421258]  [<ffffffff81118da8>] __perf_event_overflow+0x1b8/0x290
      [  434.421258]  [<ffffffff81065240>] ? tg_shares_up+0x0/0x670
      [  434.421258]  [<ffffffff8104fe1a>] ? walk_tg_tree+0x6a/0xb0
      [  434.421258]  [<ffffffff81118f44>] perf_swevent_overflow+0xc4/0xf0
      [  434.421258]  [<ffffffff81119150>] do_perf_sw_event+0x1e0/0x250
      [  434.421258]  [<ffffffff81119204>] perf_tp_event+0x44/0x70
      [  434.421258]  [<ffffffff8105701f>] ftrace_profile_sched_block+0xdf/0x110
      [  434.421258]  [<ffffffff8106121d>] dequeue_entity+0x2ad/0x2d0
      [  434.421258]  [<ffffffff810614ec>] dequeue_task_fair+0x1c/0x60
      [  434.421258]  [<ffffffff8105818a>] dequeue_task+0x9a/0xb0
      [  434.421258]  [<ffffffff810581e2>] deactivate_task+0x42/0xe0
      [  434.421258]  [<ffffffff814bc019>] thread_return+0x191/0x808
      [  434.421258]  [<ffffffff81098a44>] ? switch_task_namespaces+0x24/0x60
      [  434.421258]  [<ffffffff8106f4c4>] do_exit+0x464/0x910
      [  434.421258]  [<ffffffff8106f9c8>] do_group_exit+0x58/0xd0
      [  434.421258]  [<ffffffff8106fa57>] sys_exit_group+0x17/0x20
      [  434.421258]  [<ffffffff8100b202>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: stable@kernel.org
      Link: http://lkml.kernel.org/r/1314693156-24131-1-git-send-email-avagin@openvz.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      20afc60f
  5. 30 8月, 2011 1 次提交
    • D
      KVM: Fix instruction size issue in pvclock scaling · 3b217116
      Duncan Sands 提交于
      Commit de2d1a52 ("KVM: Fix register corruption in pvclock_scale_delta")
      introduced a mul instruction that may have only a memory operand; the
      assembler therefore cannot select the correct size:
      
         pvclock.s:229: Error: no instruction mnemonic suffix given and no register
      operands; can't size instruction
      
      In this example the assembler is:
      
               #APP
               mul -48(%rbp) ; shrd $32, %rdx, %rax
               #NO_APP
      
      A simple solution is to use mulq.
      Signed-off-by: NDuncan Sands <baldrick@free.fr>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      3b217116
  6. 27 8月, 2011 2 次提交
  7. 26 8月, 2011 2 次提交
  8. 24 8月, 2011 1 次提交
  9. 22 8月, 2011 2 次提交
  10. 17 8月, 2011 2 次提交
    • J
      xen/x86: replace order-based range checking of M2P table by linear one · ccbcdf7c
      Jan Beulich 提交于
      The order-based approach is not only less efficient (requiring a shift
      and a compare, typical generated code looking like this
      
      	mov	eax, [machine_to_phys_order]
      	mov	ecx, eax
      	shr	ebx, cl
      	test	ebx, ebx
      	jnz	...
      
      whereas a direct check requires just a compare, like in
      
      	cmp	ebx, [machine_to_phys_nr]
      	jae	...
      
      ), but also slightly dangerous in the 32-on-64 case - the element
      address calculation can wrap if the next power of two boundary is
      sufficiently far away from the actual upper limit of the table, and
      hence can result in user space addresses being accessed (with it being
      unknown what may actually be mapped there).
      
      Additionally, the elimination of the mistaken use of fls() here (should
      have been __fls()) fixes a latent issue on x86-64 that would trigger
      if the code was run on a system with memory extending beyond the 44-bit
      boundary.
      
      CC: stable@kernel.org
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      [v1: Based on Jeremy's feedback]
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ccbcdf7c
    • R
      KVM: uses TASKSTATS, depends on NET · df3d8ae1
      Randy Dunlap 提交于
      CONFIG_TASKSTATS just had a change to use netlink, including
      a change to "depends on NET".  Since "select" does not follow
      dependencies, KVM also needs to depend on NET to prevent build
      errors when CONFIG_NET is not enabled.
      
      Sample of the reported "undefined reference" build errors:
      
      taskstats.c:(.text+0x8f686): undefined reference to `nla_put'
      taskstats.c:(.text+0x8f721): undefined reference to `nla_reserve'
      taskstats.c:(.text+0x8f8fb): undefined reference to `init_net'
      taskstats.c:(.text+0x8f905): undefined reference to `netlink_unicast'
      taskstats.c:(.text+0x8f934): undefined reference to `kfree_skb'
      taskstats.c:(.text+0x8f9e9): undefined reference to `skb_clone'
      taskstats.c:(.text+0x90060): undefined reference to `__alloc_skb'
      taskstats.c:(.text+0x901e9): undefined reference to `skb_put'
      taskstats.c:(.init.text+0x4665): undefined reference to `genl_register_family'
      taskstats.c:(.init.text+0x4699): undefined reference to `genl_register_ops'
      taskstats.c:(.init.text+0x4710): undefined reference to `genl_unregister_ops'
      taskstats.c:(.init.text+0x471c): undefined reference to `genl_unregister_family'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      df3d8ae1
  11. 16 8月, 2011 1 次提交
  12. 11 8月, 2011 3 次提交
  13. 09 8月, 2011 1 次提交
  14. 06 8月, 2011 2 次提交
  15. 05 8月, 2011 10 次提交
  16. 04 8月, 2011 5 次提交
  17. 03 8月, 2011 1 次提交
  18. 02 8月, 2011 1 次提交
    • J
      PCI: Set PCI-E Max Payload Size on fabric · b03e7495
      Jon Mason 提交于
      On a given PCI-E fabric, each device, bridge, and root port can have a
      different PCI-E maximum payload size.  There is a sizable performance
      boost for having the largest possible maximum payload size on each PCI-E
      device.  However, if improperly configured, fatal bus errors can occur.
      Thus, it is important to ensure that PCI-E payloads sends by a device
      are never larger than the MPS setting of all devices on the way to the
      destination.
      
      This can be achieved two ways:
      
      - A conservative approach is to use the smallest common denominator of
        the entire tree below a root complex for every device on that fabric.
      
      This means for example that having a 128 bytes MPS USB controller on one
      leg of a switch will dramatically reduce performances of a video card or
      10GE adapter on another leg of that same switch.
      
      It also means that any hierarchy supporting hotplug slots (including
      expresscard or thunderbolt I suppose, dbl check that) will have to be
      entirely clamped to 128 bytes since we cannot predict what will be
      plugged into those slots, and we cannot change the MPS on a "live"
      system.
      
      - A more optimal way is possible, if it falls within a couple of
        constraints:
      * The top-level host bridge will never generate packets larger than the
        smallest TLP (or if it can be controlled independently from its MPS at
        least)
      * The device will never generate packets larger than MPS (which can be
        configured via MRRS)
      * No support of direct PCI-E <-> PCI-E transfers between devices without
        some additional code to specifically deal with that case
      
      Then we can use an approach that basically ignores downstream requests
      and focuses exclusively on upstream requests. In that case, all we need
      to care about is that a device MPS is no larger than its parent MPS,
      which allows us to keep all switches/bridges to the max MPS supported by
      their parent and eventually the PHB.
      
      In this case, your USB controller would no longer "starve" your 10GE
      Ethernet and your hotplug slots won't affect your global MPS.
      Additionally, the hotplugged devices themselves can be configured to a
      larger MPS up to the value configured in the hotplug bridge.
      
      To choose between the two available options, two PCI kernel boot args
      have been added to the PCI calls.  "pcie_bus_safe" will provide the
      former behavior, while "pcie_bus_perf" will perform the latter behavior.
      By default, the latter behavior is used.
      
      NOTE: due to the location of the enablement, each arch will need to add
      calls to this function.  This patch only enables x86.
      
      This patch includes a number of changes recommended by Benjamin
      Herrenschmidt.
      
      Tested-by: Jordan_Hargrave@dell.com
      Signed-off-by: NJon Mason <mason@myri.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b03e7495
  19. 27 7月, 2011 1 次提交