1. 21 4月, 2008 3 次提交
    • M
      PCI: iommu: iotlb flushing · 5e0d2a6f
      mark gross 提交于
      This patch is for batching up the flushing of the IOTLB for the DMAR
      implementation found in the Intel VT-d hardware.  It works by building a list
      of to be flushed IOTLB entries and a bitmap list of which DMAR engine they are
      from.
      
      After either a high water mark (250 accessible via debugfs) or 10ms the list
      of iova's will be reclaimed and the DMAR engines associated are IOTLB-flushed.
      
      This approach recovers 15 to 20% of the performance lost when using the IOMMU
      for my netperf udp stream benchmark with small packets.  It can be disabled
      with a kernel boot parameter "intel_iommu=strict".
      
      Its use does weaken the IOMMU protections a bit.
      Signed-off-by: NMark Gross <mgross@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5e0d2a6f
    • G
      PCI: remove initial bios sort of PCI devices on x86 · 1ba6ab11
      Greg Kroah-Hartman 提交于
      We currently keep 2 lists of PCI devices in the system, one in the
      driver core, and one all on its own.  This second list is sorted at boot
      time, in "BIOS" order, to try to remain compatible with older kernels
      (2.2 and earlier days).  There was also a "nosort" option to turn this
      sorting off, to remain compatible with even older kernel versions, but
      that just ends up being what we have been doing from 2.5 days...
      
      Unfortunately, the second list of devices is not really ever used to 
      determine the probing order of PCI devices or drivers[1].  That is done
      using the driver core list instead.  This change happened back in the
      early 2.5 days.
      
      Relying on BIOS ording for the binding of drivers to specific device
      names is problematic for many reasons, and userspace tools like udev
      exist to properly name devices in a persistant manner if that is needed,
      no reliance on the BIOS is needed.
      
      Matt Domsch and others at Dell noticed this back in 2006, and added a
      boot option to sort the PCI device lists (both of them) in a
      breadth-first manner to help remain compatible with the 2.4 order, if
      needed for any reason.  This option is not going away, as some systems
      rely on them.
      
      This patch removes the sorting of the internal PCI device list in "BIOS"
      mode, as it's not needed at all anymore, and hasn't for many years.
      I've also removed the PCI flags for this from some other arches that for
      some reason defined them, but never used them.
      
      This should not change the ordering of any drivers or device probing.
      
      [1] The old-style pci_get_device and pci_find_device() still used this
      sorting order, but there are very few drivers that use these functions,
      as they are deprecated for use in this manner.  If for some reason, a
      driver rely on the order and uses these functions, the breadth-first
      boot option will resolve any problem.
      
      Cc: Matt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1ba6ab11
    • R
      PCI: doc/pci: create Documentation/PCI/ and move files into it · 4b5ff469
      Randy Dunlap 提交于
      Create Documentation/PCI/ and move PCI-related files to it.
      Fix a few instances of trailing whitespace.
      Update references to the new file locations.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4b5ff469
  2. 19 4月, 2008 1 次提交
    • A
      Security: Introduce security= boot parameter · 076c54c5
      Ahmed S. Darwish 提交于
      Add the security= boot parameter. This is done to avoid LSM
      registration clashes in case of more than one bult-in module.
      
      User can choose a security module to enable at boot. If no
      security= boot parameter is specified, only the first LSM
      asking for registration will be loaded. An invalid security
      module name will be treated as if no module has been chosen.
      
      LSM modules must check now if they are allowed to register
      by calling security_module_enable(ops) first. Modify SELinux
      and SMACK to do so.
      
      Do not let SMACK register smackfs if it was not chosen on
      boot. Smackfs assumes that smack hooks are registered and
      the initial task security setup (swapper->security) is done.
      Signed-off-by: NAhmed S. Darwish <darwish.07@gmail.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      076c54c5
  3. 18 4月, 2008 14 次提交
  4. 17 4月, 2008 10 次提交
  5. 16 4月, 2008 2 次提交
  6. 15 4月, 2008 2 次提交
  7. 12 4月, 2008 4 次提交
  8. 09 4月, 2008 1 次提交
  9. 08 4月, 2008 2 次提交
  10. 05 4月, 2008 1 次提交
    • P
      cgroups: add cgroup support for enabling controllers at boot time · 8bab8dde
      Paul Menage 提交于
      The effects of cgroup_disable=foo are:
      
      - foo isn't auto-mounted if you mount all cgroups in a single hierarchy
      - foo isn't visible as an individually mountable subsystem
      
      As a result there will only ever be one call to foo->create(), at init time;
      all processes will stay in this group, and the group will never be mounted on
      a visible hierarchy.  Any additional effects (e.g.  not allocating metadata)
      are up to the foo subsystem.
      
      This doesn't handle early_init subsystems (their "disabled" bit isn't set be,
      but it could easily be extended to do so if any of the early_init systems
      wanted it - I think it would just involve some nastier parameter processing
      since it would occur before the command-line argument parser had been run.
      
      Hugh said:
      
        Ballpark figures, I'm trying to get this question out rather than
        processing the exact numbers: CONFIG_CGROUP_MEM_RES_CTLR adds 15% overhead
        to the affected paths, booting with cgroup_disable=memory cuts that back to
        1% overhead (due to slightly bigger struct page).
      
        I'm no expert on distros, they may have no interest whatever in
        CONFIG_CGROUP_MEM_RES_CTLR=y; and the rest of us can easily build with or
        without it, or apply the cgroup_disable=memory patches.
      
      Unix bench's execl test result on x86_64 was
      
      == just after boot without mounting any cgroup fs.==
      mem_cgorup=off : Execl Throughput       43.0     3150.1      732.6
      mem_cgroup=on  : Execl Throughput       43.0     2932.6      682.0
      ==
      
      [lizf@cn.fujitsu.com: fix boot option parsing]
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Sudhir Kumar <skumar@linux.vnet.ibm.com>
      Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bab8dde