You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'linus' into core/generic-dma-coherent
Conflicts: arch/x86/Kconfig Signed-off-by: Ingo Molnar <mingo@elte.hu>
This commit is contained in:
Ingo Molnar
@@ -317,6 +317,14 @@ S: 2322 37th Ave SW
|
||||
S: Seattle, Washington 98126-2010
|
||||
S: USA
|
||||
|
||||
N: Muli Ben-Yehuda
|
||||
E: mulix@mulix.org
|
||||
E: muli@il.ibm.com
|
||||
W: http://www.mulix.org
|
||||
D: trident OSS sound driver, x86-64 dma-ops and Calgary IOMMU,
|
||||
D: KVM and Xen bits and other misc. hackery.
|
||||
S: Haifa, Israel
|
||||
|
||||
N: Johannes Berg
|
||||
E: johannes@sipsolutions.net
|
||||
W: http://johannes.sipsolutions.net/
|
||||
@@ -3344,8 +3352,7 @@ S: Spain
|
||||
N: Linus Torvalds
|
||||
E: torvalds@linux-foundation.org
|
||||
D: Original kernel hacker
|
||||
S: 12725 SW Millikan Way, Suite 400
|
||||
S: Beaverton, Oregon 97005
|
||||
S: Portland, Oregon 97005
|
||||
S: USA
|
||||
|
||||
N: Marcelo Tosatti
|
||||
|
||||
@@ -361,8 +361,6 @@ telephony/
|
||||
- directory with info on telephony (e.g. voice over IP) support.
|
||||
time_interpolators.txt
|
||||
- info on time interpolators.
|
||||
tipar.txt
|
||||
- information about Parallel link cable for Texas Instruments handhelds.
|
||||
tty.txt
|
||||
- guide to the locking policies of the tty layer.
|
||||
uml/
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
What: /sys/dev
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Dan Williams <dan.j.williams@intel.com>
|
||||
Description: The /sys/dev tree provides a method to look up the sysfs
|
||||
path for a device using the information returned from
|
||||
stat(2). There are two directories, 'block' and 'char',
|
||||
beneath /sys/dev containing symbolic links with names of
|
||||
the form "<major>:<minor>". These links point to the
|
||||
corresponding sysfs path for the given device.
|
||||
|
||||
Example:
|
||||
$ readlink /sys/dev/block/8:32
|
||||
../../block/sdc
|
||||
|
||||
Entries in /sys/dev/char and /sys/dev/block will be
|
||||
dynamically created and destroyed as devices enter and
|
||||
leave the system.
|
||||
|
||||
Users: mdadm <linux-raid@vger.kernel.org>
|
||||
@@ -0,0 +1,24 @@
|
||||
What: /sys/devices/system/memory
|
||||
Date: June 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The /sys/devices/system/memory contains a snapshot of the
|
||||
internal state of the kernel memory blocks. Files could be
|
||||
added or removed dynamically to represent hot-add/remove
|
||||
operations.
|
||||
|
||||
Users: hotplug memory add/remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/removable
|
||||
Date: June 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/removable
|
||||
indicates whether this memory block is removable or not.
|
||||
This is useful for a user-level agent to determine
|
||||
identify removable sections of the memory before attempting
|
||||
potentially expensive hot-remove memory operation
|
||||
|
||||
Users: hotplug memory remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
@@ -0,0 +1,6 @@
|
||||
What: /sys/kernel/mm
|
||||
Date: July 2008
|
||||
Contact: Nishanth Aravamudan <nacc@us.ibm.com>, VM maintainers
|
||||
Description:
|
||||
/sys/kernel/mm/ should contain any and all VM
|
||||
related information in /sys/kernel/.
|
||||
@@ -0,0 +1,15 @@
|
||||
What: /sys/kernel/mm/hugepages/
|
||||
Date: June 2008
|
||||
Contact: Nishanth Aravamudan <nacc@us.ibm.com>, hugetlb maintainers
|
||||
Description:
|
||||
/sys/kernel/mm/hugepages/ contains a number of subdirectories
|
||||
of the form hugepages-<size>kB, where <size> is the page size
|
||||
of the hugepages supported by the kernel/CPU combination.
|
||||
|
||||
Under these directories are a number of files:
|
||||
nr_hugepages
|
||||
nr_overcommit_hugepages
|
||||
free_hugepages
|
||||
surplus_hugepages
|
||||
resv_hugepages
|
||||
See Documentation/vm/hugetlbpage.txt for details.
|
||||
+21
-17
@@ -474,25 +474,29 @@ make a good program).
|
||||
So, you can either get rid of GNU emacs, or change it to use saner
|
||||
values. To do the latter, you can stick the following in your .emacs file:
|
||||
|
||||
(defun linux-c-mode ()
|
||||
"C mode with adjusted defaults for use with the Linux kernel."
|
||||
(interactive)
|
||||
(c-mode)
|
||||
(c-set-style "K&R")
|
||||
(setq tab-width 8)
|
||||
(setq indent-tabs-mode t)
|
||||
(setq c-basic-offset 8))
|
||||
(defun c-lineup-arglist-tabs-only (ignored)
|
||||
"Line up argument lists by tabs, not spaces"
|
||||
(let* ((anchor (c-langelem-pos c-syntactic-element))
|
||||
(column (c-langelem-2nd-pos c-syntactic-element))
|
||||
(offset (- (1+ column) anchor))
|
||||
(steps (floor offset c-basic-offset)))
|
||||
(* (max steps 1)
|
||||
c-basic-offset)))
|
||||
|
||||
This will define the M-x linux-c-mode command. When hacking on a
|
||||
module, if you put the string -*- linux-c -*- somewhere on the first
|
||||
two lines, this mode will be automatically invoked. Also, you may want
|
||||
to add
|
||||
(add-hook 'c-mode-hook
|
||||
(lambda ()
|
||||
(let ((filename (buffer-file-name)))
|
||||
;; Enable kernel mode for the appropriate files
|
||||
(when (and filename
|
||||
(string-match "~/src/linux-trees" filename))
|
||||
(setq indent-tabs-mode t)
|
||||
(c-set-style "linux")
|
||||
(c-set-offset 'arglist-cont-nonempty
|
||||
'(c-lineup-gcc-asm-reg
|
||||
c-lineup-arglist-tabs-only))))))
|
||||
|
||||
(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
|
||||
auto-mode-alist))
|
||||
|
||||
to your .emacs file if you want to have linux-c-mode switched on
|
||||
automagically when you edit source files under /usr/src/linux.
|
||||
This will make emacs go better with the kernel coding style for C
|
||||
files below ~/src/linux-trees.
|
||||
|
||||
But even if you fail in getting emacs to do sane formatting, not
|
||||
everything is lost: use "indent".
|
||||
|
||||
@@ -298,10 +298,10 @@ recommended that you never use these unless you really know what the
|
||||
cache width is.
|
||||
|
||||
int
|
||||
dma_mapping_error(dma_addr_t dma_addr)
|
||||
dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
|
||||
|
||||
int
|
||||
pci_dma_mapping_error(dma_addr_t dma_addr)
|
||||
pci_dma_mapping_error(struct pci_dev *hwdev, dma_addr_t dma_addr)
|
||||
|
||||
In some circumstances dma_map_single and dma_map_page will fail to create
|
||||
a mapping. A driver can check for these errors by testing the returned
|
||||
|
||||
@@ -22,3 +22,12 @@ ready and available in memory. The DMA of the "completion indication"
|
||||
could race with data DMA. Mapping the memory used for completion
|
||||
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
|
||||
|
||||
DMA_ATTR_WEAK_ORDERING
|
||||
----------------------
|
||||
|
||||
DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping
|
||||
may be weakly ordered, that is that reads and writes may pass each other.
|
||||
|
||||
Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
|
||||
those that do not will simply ignore the attribute and exhibit default
|
||||
behavior.
|
||||
|
||||
@@ -524,6 +524,44 @@ These utilities include endpoint autoconfiguration.
|
||||
<!-- !Edrivers/usb/gadget/epautoconf.c -->
|
||||
</sect1>
|
||||
|
||||
<sect1 id="composite"><title>Composite Device Framework</title>
|
||||
|
||||
<para>The core API is sufficient for writing drivers for composite
|
||||
USB devices (with more than one function in a given configuration),
|
||||
and also multi-configuration devices (also more than one function,
|
||||
but not necessarily sharing a given configuration).
|
||||
There is however an optional framework which makes it easier to
|
||||
reuse and combine functions.
|
||||
</para>
|
||||
|
||||
<para>Devices using this framework provide a <emphasis>struct
|
||||
usb_composite_driver</emphasis>, which in turn provides one or
|
||||
more <emphasis>struct usb_configuration</emphasis> instances.
|
||||
Each such configuration includes at least one
|
||||
<emphasis>struct usb_function</emphasis>, which packages a user
|
||||
visible role such as "network link" or "mass storage device".
|
||||
Management functions may also exist, such as "Device Firmware
|
||||
Upgrade".
|
||||
</para>
|
||||
|
||||
!Iinclude/linux/usb/composite.h
|
||||
!Edrivers/usb/gadget/composite.c
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="functions"><title>Composite Device Functions</title>
|
||||
|
||||
<para>At this writing, a few of the current gadget drivers have
|
||||
been converted to this framework.
|
||||
Near-term plans include converting all of them, except for "gadgetfs".
|
||||
</para>
|
||||
|
||||
!Edrivers/usb/gadget/f_acm.c
|
||||
!Edrivers/usb/gadget/f_serial.c
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="controllers"><title>Peripheral Controller Drivers</title>
|
||||
|
||||
@@ -219,10 +219,10 @@
|
||||
</para>
|
||||
|
||||
<sect1 id="lock-intro">
|
||||
<title>Three Main Types of Kernel Locks: Spinlocks, Mutexes and Semaphores</title>
|
||||
<title>Two Main Types of Kernel Locks: Spinlocks and Mutexes</title>
|
||||
|
||||
<para>
|
||||
There are three main types of kernel locks. The fundamental type
|
||||
There are two main types of kernel locks. The fundamental type
|
||||
is the spinlock
|
||||
(<filename class="headerfile">include/asm/spinlock.h</filename>),
|
||||
which is a very simple single-holder lock: if you can't get the
|
||||
@@ -239,14 +239,6 @@
|
||||
can't sleep (see <xref linkend="sleeping-things"/>), and so have to
|
||||
use a spinlock instead.
|
||||
</para>
|
||||
<para>
|
||||
The third type is a semaphore
|
||||
(<filename class="headerfile">include/linux/semaphore.h</filename>): it
|
||||
can have more than one holder at any time (the number decided at
|
||||
initialization time), although it is most commonly used as a
|
||||
single-holder lock (a mutex). If you can't get a semaphore, your
|
||||
task will be suspended and later on woken up - just like for mutexes.
|
||||
</para>
|
||||
<para>
|
||||
Neither type of lock is recursive: see
|
||||
<xref linkend="deadlock"/>.
|
||||
@@ -278,7 +270,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Semaphores still exist, because they are required for
|
||||
Mutexes still exist, because they are required for
|
||||
synchronization between <firstterm linkend="gloss-usercontext">user
|
||||
contexts</firstterm>, as we will see below.
|
||||
</para>
|
||||
@@ -289,18 +281,17 @@
|
||||
|
||||
<para>
|
||||
If you have a data structure which is only ever accessed from
|
||||
user context, then you can use a simple semaphore
|
||||
(<filename>linux/linux/semaphore.h</filename>) to protect it. This
|
||||
is the most trivial case: you initialize the semaphore to the number
|
||||
of resources available (usually 1), and call
|
||||
<function>down_interruptible()</function> to grab the semaphore, and
|
||||
<function>up()</function> to release it. There is also a
|
||||
<function>down()</function>, which should be avoided, because it
|
||||
user context, then you can use a simple mutex
|
||||
(<filename>include/linux/mutex.h</filename>) to protect it. This
|
||||
is the most trivial case: you initialize the mutex. Then you can
|
||||
call <function>mutex_lock_interruptible()</function> to grab the mutex,
|
||||
and <function>mutex_unlock()</function> to release it. There is also a
|
||||
<function>mutex_lock()</function>, which should be avoided, because it
|
||||
will not return if a signal is received.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example: <filename>linux/net/core/netfilter.c</filename> allows
|
||||
Example: <filename>net/netfilter/nf_sockopt.c</filename> allows
|
||||
registration of new <function>setsockopt()</function> and
|
||||
<function>getsockopt()</function> calls, with
|
||||
<function>nf_register_sockopt()</function>. Registration and
|
||||
@@ -515,7 +506,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
If you are in a process context (any syscall) and want to
|
||||
lock other process out, use a semaphore. You can take a semaphore
|
||||
lock other process out, use a mutex. You can take a mutex
|
||||
and sleep (<function>copy_from_user*(</function> or
|
||||
<function>kmalloc(x,GFP_KERNEL)</function>).
|
||||
</para>
|
||||
@@ -662,7 +653,7 @@
|
||||
<entry>SLBH</entry>
|
||||
<entry>SLBH</entry>
|
||||
<entry>SLBH</entry>
|
||||
<entry>DI</entry>
|
||||
<entry>MLI</entry>
|
||||
<entry>None</entry>
|
||||
</row>
|
||||
|
||||
@@ -692,8 +683,8 @@
|
||||
<entry>spin_lock_bh</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>DI</entry>
|
||||
<entry>down_interruptible</entry>
|
||||
<entry>MLI</entry>
|
||||
<entry>mutex_lock_interruptible</entry>
|
||||
</row>
|
||||
|
||||
</tbody>
|
||||
@@ -1310,7 +1301,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
|
||||
<para>
|
||||
There is a coding bug where a piece of code tries to grab a
|
||||
spinlock twice: it will spin forever, waiting for the lock to
|
||||
be released (spinlocks, rwlocks and semaphores are not
|
||||
be released (spinlocks, rwlocks and mutexes are not
|
||||
recursive in Linux). This is trivial to diagnose: not a
|
||||
stay-up-five-nights-talk-to-fluffy-code-bunnies kind of
|
||||
problem.
|
||||
@@ -1335,7 +1326,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
|
||||
|
||||
<para>
|
||||
This complete lockup is easy to diagnose: on SMP boxes the
|
||||
watchdog timer or compiling with <symbol>DEBUG_SPINLOCKS</symbol> set
|
||||
watchdog timer or compiling with <symbol>DEBUG_SPINLOCK</symbol> set
|
||||
(<filename>include/linux/spinlock.h</filename>) will show this up
|
||||
immediately when it happens.
|
||||
</para>
|
||||
@@ -1558,7 +1549,7 @@ the amount of locking which needs to be done.
|
||||
<title>Read/Write Lock Variants</title>
|
||||
|
||||
<para>
|
||||
Both spinlocks and semaphores have read/write variants:
|
||||
Both spinlocks and mutexes have read/write variants:
|
||||
<type>rwlock_t</type> and <structname>struct rw_semaphore</structname>.
|
||||
These divide users into two classes: the readers and the writers. If
|
||||
you are only reading the data, you can get a read lock, but to write to
|
||||
@@ -1681,7 +1672,7 @@ the amount of locking which needs to be done.
|
||||
#include <linux/slab.h>
|
||||
#include <linux/string.h>
|
||||
+#include <linux/rcupdate.h>
|
||||
#include <linux/semaphore.h>
|
||||
#include <linux/mutex.h>
|
||||
#include <asm/errno.h>
|
||||
|
||||
struct object
|
||||
@@ -1913,7 +1904,7 @@ machines due to caching.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<function> put_user()</function>
|
||||
<function>put_user()</function>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@@ -1927,13 +1918,13 @@ machines due to caching.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<function>down_interruptible()</function> and
|
||||
<function>down()</function>
|
||||
<function>mutex_lock_interruptible()</function> and
|
||||
<function>mutex_lock()</function>
|
||||
</para>
|
||||
<para>
|
||||
There is a <function>down_trylock()</function> which can be
|
||||
There is a <function>mutex_trylock()</function> which can be
|
||||
used inside interrupt context, as it will not sleep.
|
||||
<function>up()</function> will also never sleep.
|
||||
<function>mutex_unlock()</function> will also never sleep.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@@ -2023,7 +2014,7 @@ machines due to caching.
|
||||
<para>
|
||||
Prior to 2.5, or when <symbol>CONFIG_PREEMPT</symbol> is
|
||||
unset, processes in user context inside the kernel would not
|
||||
preempt each other (ie. you had that CPU until you have it up,
|
||||
preempt each other (ie. you had that CPU until you gave it up,
|
||||
except for interrupts). With the addition of
|
||||
<symbol>CONFIG_PREEMPT</symbol> in 2.5.4, this changed: when
|
||||
in user context, higher priority tasks can "cut in": spinlocks
|
||||
|
||||
@@ -29,12 +29,12 @@
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>1.0 </revnumber>
|
||||
<revnumber>1.0</revnumber>
|
||||
<date>May 30, 2001</date>
|
||||
<revremark>Initial revision posted to linux-kernel</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1 </revnumber>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>June 3, 2001</date>
|
||||
<revremark>Revised after comments from linux-kernel</revremark>
|
||||
</revision>
|
||||
|
||||
@@ -21,6 +21,18 @@
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<copyright>
|
||||
<year>2006-2008</year>
|
||||
<holder>Hans-Jürgen Koch.</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This documentation is Free Software licensed under the terms of the
|
||||
GPL version 2.
|
||||
</para>
|
||||
</legalnotice>
|
||||
|
||||
<pubdate>2006-12-11</pubdate>
|
||||
|
||||
<abstract>
|
||||
@@ -29,6 +41,12 @@
|
||||
</abstract>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>0.5</revnumber>
|
||||
<date>2008-05-22</date>
|
||||
<authorinitials>hjk</authorinitials>
|
||||
<revremark>Added description of write() function.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>0.4</revnumber>
|
||||
<date>2007-11-26</date>
|
||||
@@ -57,20 +75,9 @@
|
||||
</bookinfo>
|
||||
|
||||
<chapter id="aboutthisdoc">
|
||||
<?dbhtml filename="about.html"?>
|
||||
<?dbhtml filename="aboutthis.html"?>
|
||||
<title>About this document</title>
|
||||
|
||||
<sect1 id="copyright">
|
||||
<?dbhtml filename="copyright.html"?>
|
||||
<title>Copyright and License</title>
|
||||
<para>
|
||||
Copyright (c) 2006 by Hans-Jürgen Koch.</para>
|
||||
<para>
|
||||
This documentation is Free Software licensed under the terms of the
|
||||
GPL version 2.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="translations">
|
||||
<?dbhtml filename="translations.html"?>
|
||||
<title>Translations</title>
|
||||
@@ -189,6 +196,30 @@ interested in translating it, please email me
|
||||
represents the total interrupt count. You can use this number
|
||||
to figure out if you missed some interrupts.
|
||||
</para>
|
||||
<para>
|
||||
For some hardware that has more than one interrupt source internally,
|
||||
but not separate IRQ mask and status registers, there might be
|
||||
situations where userspace cannot determine what the interrupt source
|
||||
was if the kernel handler disables them by writing to the chip's IRQ
|
||||
register. In such a case, the kernel has to disable the IRQ completely
|
||||
to leave the chip's register untouched. Now the userspace part can
|
||||
determine the cause of the interrupt, but it cannot re-enable
|
||||
interrupts. Another cornercase is chips where re-enabling interrupts
|
||||
is a read-modify-write operation to a combined IRQ status/acknowledge
|
||||
register. This would be racy if a new interrupt occurred
|
||||
simultaneously.
|
||||
</para>
|
||||
<para>
|
||||
To address these problems, UIO also implements a write() function. It
|
||||
is normally not used and can be ignored for hardware that has only a
|
||||
single interrupt source or has separate IRQ mask and status registers.
|
||||
If you need it, however, a write to <filename>/dev/uioX</filename>
|
||||
will call the <function>irqcontrol()</function> function implemented
|
||||
by the driver. You have to write a 32-bit value that is usually either
|
||||
0 or 1 to disable or enable interrupts. If a driver does not implement
|
||||
<function>irqcontrol()</function>, <function>write()</function> will
|
||||
return with <varname>-ENOSYS</varname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To handle interrupts properly, your custom kernel module can
|
||||
@@ -362,6 +393,14 @@ device is actually used.
|
||||
<function>open()</function>, you will probably also want a custom
|
||||
<function>release()</function> function.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>int (*irqcontrol)(struct uio_info *info, s32 irq_on)
|
||||
</varname>: Optional. If you need to be able to enable or disable
|
||||
interrupts from userspace by writing to <filename>/dev/uioX</filename>,
|
||||
you can implement this function. The parameter <varname>irq_on</varname>
|
||||
will be 0 to disable interrupts and 1 to enable them.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
|
||||
+1
-1
@@ -358,7 +358,7 @@ Here is a list of some of the different kernel trees available:
|
||||
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
|
||||
|
||||
- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
|
||||
- SCSI, James Bottomley <James.Bottomley@hansenpartnership.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
|
||||
|
||||
- x86, Ingo Molnar <mingo@elte.hu>
|
||||
|
||||
@@ -48,7 +48,7 @@ IOVA generation is pretty generic. We used the same technique as vmalloc()
|
||||
but these are not global address spaces, but separate for each domain.
|
||||
Different DMA engines may support different number of domains.
|
||||
|
||||
We also allocate gaurd pages with each mapping, so we can attempt to catch
|
||||
We also allocate guard pages with each mapping, so we can attempt to catch
|
||||
any overflow that might happen.
|
||||
|
||||
|
||||
@@ -112,4 +112,4 @@ TBD
|
||||
|
||||
- For compatibility testing, could use unity map domain for all devices, just
|
||||
provide a 1-1 for all useful memory under a single domain for all devices.
|
||||
- API for paravirt ops for abstracting functionlity for VMM folks.
|
||||
- API for paravirt ops for abstracting functionality for VMM folks.
|
||||
|
||||
@@ -528,7 +528,33 @@ See more details on the proper patch format in the following
|
||||
references.
|
||||
|
||||
|
||||
16) Sending "git pull" requests (from Linus emails)
|
||||
|
||||
Please write the git repo address and branch name alone on the same line
|
||||
so that I can't even by mistake pull from the wrong branch, and so
|
||||
that a triple-click just selects the whole thing.
|
||||
|
||||
So the proper format is something along the lines of:
|
||||
|
||||
"Please pull from
|
||||
|
||||
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
|
||||
|
||||
to get these changes:"
|
||||
|
||||
so that I don't have to hunt-and-peck for the address and inevitably
|
||||
get it wrong (actually, I've only gotten it wrong a few times, and
|
||||
checking against the diffstat tells me when I get it wrong, but I'm
|
||||
just a lot more comfortable when I don't have to "look for" the right
|
||||
thing to pull, and double-check that I have the right branch-name).
|
||||
|
||||
|
||||
Please use "git diff -M --stat --summary" to generate the diffstat:
|
||||
the -M enables rename detection, and the summary enables a summary of
|
||||
new/deleted or renamed files.
|
||||
|
||||
With rename detection, the statistics are rather different [...]
|
||||
because git will notice that a fair number of the changes are renames.
|
||||
|
||||
-----------------------------------
|
||||
SECTION 2 - HINTS, TIPS, AND TRICKS
|
||||
|
||||
@@ -11,6 +11,7 @@ the delays experienced by a task while
|
||||
a) waiting for a CPU (while being runnable)
|
||||
b) completion of synchronous block I/O initiated by the task
|
||||
c) swapping in pages
|
||||
d) memory reclaim
|
||||
|
||||
and makes these statistics available to userspace through
|
||||
the taskstats interface.
|
||||
@@ -41,7 +42,7 @@ this structure. See
|
||||
include/linux/taskstats.h
|
||||
for a description of the fields pertaining to delay accounting.
|
||||
It will generally be in the form of counters returning the cumulative
|
||||
delay seen for cpu, sync block I/O, swapin etc.
|
||||
delay seen for cpu, sync block I/O, swapin, memory reclaim etc.
|
||||
|
||||
Taking the difference of two successive readings of a given
|
||||
counter (say cpu_delay_total) for a task will give the delay
|
||||
@@ -94,7 +95,9 @@ CPU count real total virtual total delay total
|
||||
7876 92005750 100000000 24001500
|
||||
IO count delay total
|
||||
0 0
|
||||
MEM count delay total
|
||||
SWAP count delay total
|
||||
0 0
|
||||
RECLAIM count delay total
|
||||
0 0
|
||||
|
||||
Get delays seen in executing a given simple command
|
||||
@@ -108,5 +111,7 @@ CPU count real total virtual total delay total
|
||||
6 4000250 4000000 0
|
||||
IO count delay total
|
||||
0 0
|
||||
MEM count delay total
|
||||
SWAP count delay total
|
||||
0 0
|
||||
RECLAIM count delay total
|
||||
0 0
|
||||
|
||||
@@ -196,14 +196,18 @@ void print_delayacct(struct taskstats *t)
|
||||
" %15llu%15llu%15llu%15llu\n"
|
||||
"IO %15s%15s\n"
|
||||
" %15llu%15llu\n"
|
||||
"MEM %15s%15s\n"
|
||||
"SWAP %15s%15s\n"
|
||||
" %15llu%15llu\n"
|
||||
"RECLAIM %12s%15s\n"
|
||||
" %15llu%15llu\n",
|
||||
"count", "real total", "virtual total", "delay total",
|
||||
t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
|
||||
t->cpu_delay_total,
|
||||
"count", "delay total",
|
||||
t->blkio_count, t->blkio_delay_total,
|
||||
"count", "delay total", t->swapin_count, t->swapin_delay_total);
|
||||
"count", "delay total", t->swapin_count, t->swapin_delay_total,
|
||||
"count", "delay total",
|
||||
t->freepages_count, t->freepages_delay_total);
|
||||
}
|
||||
|
||||
void task_context_switch_counts(struct taskstats *t)
|
||||
|
||||
@@ -6,7 +6,7 @@ This document contains an explanation of the struct taskstats fields.
|
||||
There are three different groups of fields in the struct taskstats:
|
||||
|
||||
1) Common and basic accounting fields
|
||||
If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and
|
||||
If CONFIG_TASKSTATS is set, the taskstats interface is enabled and
|
||||
the common fields and basic accounting fields are collected for
|
||||
delivery at do_exit() of a task.
|
||||
2) Delay accounting fields
|
||||
@@ -26,6 +26,8 @@ There are three different groups of fields in the struct taskstats:
|
||||
|
||||
5) Time accounting for SMT machines
|
||||
|
||||
6) Extended delay accounting fields for memory reclaim
|
||||
|
||||
Future extension should add fields to the end of the taskstats struct, and
|
||||
should not change the relative position of each field within the struct.
|
||||
|
||||
@@ -170,4 +172,9 @@ struct taskstats {
|
||||
__u64 ac_utimescaled; /* utime scaled on frequency etc */
|
||||
__u64 ac_stimescaled; /* stime scaled on frequency etc */
|
||||
__u64 cpu_scaled_run_real_total; /* scaled cpu_run_real_total */
|
||||
|
||||
6) Extended delay accounting fields for memory reclaim
|
||||
/* Delay waiting for memory reclaim */
|
||||
__u64 freepages_count;
|
||||
__u64 freepages_delay_total;
|
||||
}
|
||||
|
||||
@@ -138,14 +138,8 @@ So, what's changed?
|
||||
|
||||
Set active the IRQ edge(s)/level. This replaces the
|
||||
SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
|
||||
function. Type should be one of the following:
|
||||
|
||||
#define IRQT_NOEDGE (0)
|
||||
#define IRQT_RISING (__IRQT_RISEDGE)
|
||||
#define IRQT_FALLING (__IRQT_FALEDGE)
|
||||
#define IRQT_BOTHEDGE (__IRQT_RISEDGE|__IRQT_FALEDGE)
|
||||
#define IRQT_LOW (__IRQT_LOWLVL)
|
||||
#define IRQT_HIGH (__IRQT_HIGHLVL)
|
||||
function. Type should be one of IRQ_TYPE_xxx defined in
|
||||
<linux/irq.h>
|
||||
|
||||
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user