Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 2月, 2006 1 次提交
  3. 15 1月, 2006 2 次提交
  5. 13 1月, 2006 1 次提交
    • A
      [PATCH] scheduler cache-hot-autodetect · 198e2f18
      由 akpm@osdl.org 提交于 
      )

From: Ingo Molnar <mingo@elte.hu>

This is the latest version of the scheduler cache-hot-auto-tune patch.

The first problem was that detection time scaled with O(N^2), which is
unacceptable on larger SMP and NUMA systems. To solve this:

- I've added a 'domain distance' function, which is used to cache
  measurement results. Each distance is only measured once. This means
  that e.g. on NUMA distances of 0, 1 and 2 might be measured, on HT
  distances 0 and 1, and on SMP distance 0 is measured. The code walks
  the domain tree to determine the distance, so it automatically follows
  whatever hierarchy an architecture sets up. This cuts down on the boot
  time significantly and removes the O(N^2) limit. The only assumption
  is that migration costs can be expressed as a function of domain
  distance - this covers the overwhelming majority of existing systems,
  and is a good guess even for more assymetric systems.

  [ People hacking systems that have assymetries that break this
    assumption (e.g. different CPU speeds) should experiment a bit with
    the cpu_distance() function. Adding a ->migration_distance factor to
    the domain structure would be one possible solution - but lets first
    see the problem systems, if they exist at all. Lets not overdesign. ]

Another problem was that only a single cache-size was used for measuring
the cost of migration, and most architectures didnt set that variable
up. Furthermore, a single cache-size does not fit NUMA hierarchies with
L3 caches and does not fit HT setups, where different CPUs will often
have different 'effective cache sizes'. To solve this problem:

- Instead of relying on a single cache-size provided by the platform and
  sticking to it, the code now auto-detects the 'effective migration
  cost' between two measured CPUs, via iterating through a wide range of
  cachesizes. The code searches for the maximum migration cost, which
  occurs when the working set of the test-workload falls just below the
  'effective cache size'. I.e. real-life optimized search is done for
  the maximum migration cost, between two real CPUs.

  This, amongst other things, has the positive effect hat if e.g. two
  CPUs share a L2/L3 cache, a different (and accurate) migration cost
  will be found than between two CPUs on the same system that dont share
  any caches.

(The reliable measurement of migration costs is tricky - see the source
for details.)

Furthermore i've added various boot-time options to override/tune
migration behavior.

Firstly, there's a blanket override for autodetection:

	migration_cost=1000,2000,3000

will override the depth 0/1/2 values with 1msec/2msec/3msec values.

Secondly, there's a global factor that can be used to increase (or
decrease) the autodetected values:

	migration_factor=120

will increase the autodetected values by 20%. This option is useful to
tune things in a workload-dependent way - e.g. if a workload is
cache-insensitive then CPU utilization can be maximized by specifying
migration_factor=0.

I've tested the autodetection code quite extensively on x86, on 3
P3/Xeon/2MB, and the autodetected values look pretty good:

Dual Celeron (128K L2 cache):

 ---------------------
 migration cost matrix (max_cache_size: 131072, cpu: 467 MHz):
 ---------------------
           [00]    [01]
 [00]:     -     1.7(1)
 [01]:   1.7(1)    -
 ---------------------
 cacheflush times [2]: 0.0 (0) 1.7 (1784008)
 ---------------------

Here the slow memory subsystem dominates system performance, and even
though caches are small, the migration cost is 1.7 msecs.

Dual HT P4 (512K L2 cache):

 ---------------------
 migration cost matrix (max_cache_size: 524288, cpu: 2379 MHz):
 ---------------------
           [00]    [01]    [02]    [03]
 [00]:     -     0.4(1)  0.0(0)  0.4(1)
 [01]:   0.4(1)    -     0.4(1)  0.0(0)
 [02]:   0.0(0)  0.4(1)    -     0.4(1)
 [03]:   0.4(1)  0.0(0)  0.4(1)    -
 ---------------------
 cacheflush times [2]: 0.0 (33900) 0.4 (448514)
 ---------------------

Here it can be seen that there is no migration cost between two HT
siblings (CPU#0/2 and CPU#1/3 are separate physical CPUs). A fast memory
system makes inter-physical-CPU migration pretty cheap: 0.4 msecs.

8-way P3/Xeon [2MB L2 cache]:

 ---------------------
 migration cost matrix (max_cache_size: 2097152, cpu: 700 MHz):
 ---------------------
           [00]    [01]    [02]    [03]    [04]    [05]    [06]    [07]
 [00]:     -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
 [01]:  19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
 [02]:  19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
 [03]:  19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1)
 [04]:  19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1)
 [05]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1)
 [06]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1)
 [07]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -
 ---------------------
 cacheflush times [2]: 0.0 (0) 19.2 (19281756)
 ---------------------

This one has huge caches and a relatively slow memory subsystem - so the
migration cost is 19 msecs.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NKen Chen <kenneth.w.chen@intel.com>
Cc: <wilder@us.ibm.com>
Signed-off-by: NJohn Hawkes <hawkes@sgi.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      198e2f18
  7. 11 1月, 2006 2 次提交
  9. 08 1月, 2006 1 次提交
    • D
      [SERIAL] Make the number of UARTs registered configurable. · a61c2d78
      由 Dave Jones 提交于 
      Also add a nr_uarts module option to the 8250 code to override
this, up to a maximum of CONFIG_SERIAL_8250_NR_UARTS

This should appease people who complain about a proliferation
of /dev/ttyS & /sysfs nodes whilst at the same time allowing
a single kernel image to support the rarer occasions of
lots of devices.
Signed-off-by: NDave Jones <davej@redhat.com>
      a61c2d78
  11. 07 1月, 2006 2 次提交
  13. 29 12月, 2005 1 次提交
  15. 13 12月, 2005 1 次提交
    • J
      [PATCH] add boot option to control Intel SATA/PATA combined mode · 2bd0fa3b
      由 Jesse Barnes 提交于 
      Combined mode sucks.  Especially when both libata and the legacy IDE
drivers try to drive ports on the same device, since that makes DMA
rather difficult.

This patch addresses the problem by allowing the user to control which
driver binds to the ports in a combined mode configuration.  In many
cases, they'll probably want the libata driver to control both ports
since it can use DMA for talking with ATAPI devices (when
libata.atapi_enabled=1 of course).  It also allows the user to get old
school behavior by letting the legacy IDE driver bind to both ports.
But neither is forced, the patch doesn't change current behavior unless
one of combined_mode=ide or combined_mode=libata is passed
on the boot line.  Either of those options may require you to access
your devices via different device nodes (/dev/hd* in the ide case
and /dev/sd* in the libata case), though of course if you have udev
installed nicely you may not notice anything.  :)

Let me know if the documentation is too cryptic, I'd be happy to expand
on it if necessary.  I think most users will want to boot with
'combined_mode=libata' and add 'options libata atapi_enabled=1'
to their modules.conf to get good DVD playing and disk behavior
(haven't tested CD or DVD writing though).

I'd much rather things behave sanely by default (i.e. DMA for devices on
both ports), but apparently that's difficult given the various chip
bugs and hardware configs out there (not to mention that people's
drives may suddenly change from /dev/hdc to /dev/sdb), so this boot
option may be the correct long term fix.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      2bd0fa3b
  17. 06 12月, 2005 1 次提交
  19. 30 10月, 2005 1 次提交
    • H
      [PATCH] mm: m68k kill stram swap · f9c98d02
      由 Hugh Dickins 提交于 
      Please, please now delete the Atari CONFIG_STRAM_SWAP code.  It may be
excellent and ingenious code, but its reference to swap_vfsmnt betrays that it
hasn't been built since 2.5.1 (four years old come December), it's delving
deep into matters which are the preserve of core mm code, its only purpose is
to give the more conscientious mm guys an anxiety attack from time to time;
yet we keep on breaking it more and more.

If you want to use RAM for swap, then if the MTD driver does not already
provide just what you need, I'm sure David could be persuaded to add the
extra.  But you'd also like to be able to allocate extents of that swap for
other use: we can give you a core interface for that if you need.  But unbuilt
for four years suggests to me that there's no need at all.

I cannot swear the patch below won't break your build, but believe so.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f9c98d02
  21. 29 10月, 2005 1 次提交
    • A
      [PATCH] USB: Always do usb-handoff · 478a3bab
      由 Alan Stern 提交于 
      This revised patch (as586b) makes usb-handoff permanently true and no
longer a kernel boot parameter.  It also removes the piix3_usb quirk code;
that was nothing more than an early version of the USB handoff code
(written at a time when Intel's PIIX3 was about the only motherboard with
USB support).  And it adds identifiers for the three PCI USB controller
classes to pci_ids.h.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      478a3bab
  23. 24 10月, 2005 1 次提交
  25. 13 9月, 2005 1 次提交
  27. 08 9月, 2005 1 次提交
    • O
      [PATCH] Add rdinit parameter to pick early userspace init · ffdfc409
      由 Olof Johansson 提交于 
      Since early userspace was added, there's no way to override which init to
run from it.  Some people tack on an extra cpio archive with a link from
/init depending on what they want to run, but that's sometimes impractical.

Changing the "init=" to also override the early userspace isn't feasible,
since it is still used to indicate what init to run from disk when early
userspace has completed doing whatever it's doing (i.e.  load filesystem
modules and drivers).

Instead, introduce "rdinit=" and make it override the default "/init" if
specified.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ffdfc409
  29. 04 9月, 2005 1 次提交
  31. 16 8月, 2005 1 次提交
  33. 13 7月, 2005 1 次提交
  35. 08 7月, 2005 1 次提交
  37. 29 6月, 2005 2 次提交
  39. 28 6月, 2005 1 次提交
    • J
      [PATCH] PCI Allow OutOfRange PIRQ table address · 120bb424
      由 jayalk@intworks.biz 提交于 
      I updated this to remove unnecessary variable initialization, make
check_routing be inline only and not __init, switch to strtoul, and
formatting fixes as per Randy Dunlap's recommendations.

I updated this to change pirq_table_addr to a long, and to add a warning
msg if the PIRQ table wasn't found at the specified address, as per thread
with Matthew Wilcox.

In our hardware situation, the BIOS is unable to store or generate it's PIRQ
table in the F0000h-100000h standard range. This patch adds a pci kernel
parameter, pirqaddr to allow the bootloader (or BIOS based loader) to inform
the kernel where the PIRQ table got stored. A beneficial side-effect is that,
if one's BIOS uses a static address each time for it's PIRQ table, then
pirqaddr can be used to avoid the $pirq search through that address block each
time at boot for normal PIRQ BIOSes.
Signed-off-by: NJaya Kumar <jayalk@intworks.biz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      120bb424
  41. 26 6月, 2005 3 次提交
  43. 29 5月, 2005 1 次提交
  45. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4