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 stackprotector
This commit is contained in:
Ingo Molnar
@@ -26,6 +26,7 @@ tags
|
||||
TAGS
|
||||
vmlinux*
|
||||
!vmlinux.lds.S
|
||||
!vmlinux.lds.h
|
||||
System.map
|
||||
Module.markers
|
||||
Module.symvers
|
||||
|
||||
@@ -84,10 +84,9 @@
|
||||
runs an instance of gdb against the vmlinux file which contains
|
||||
the symbols (not boot image such as bzImage, zImage, uImage...).
|
||||
In gdb the developer specifies the connection parameters and
|
||||
connects to kgdb. Depending on which kgdb I/O modules exist in
|
||||
the kernel for a given architecture, it may be possible to debug
|
||||
the test machine's kernel with the development machine using a
|
||||
rs232 or ethernet connection.
|
||||
connects to kgdb. The type of connection a developer makes with
|
||||
gdb depends on the availability of kgdb I/O modules compiled as
|
||||
builtin's or kernel modules in the test machine's kernel.
|
||||
</para>
|
||||
</chapter>
|
||||
<chapter id="CompilingAKernel">
|
||||
@@ -223,7 +222,7 @@
|
||||
</para>
|
||||
<para>
|
||||
IMPORTANT NOTE: Using this option with kgdb over the console
|
||||
(kgdboc) or kgdb over ethernet (kgdboe) is not supported.
|
||||
(kgdboc) is not supported.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
@@ -249,18 +248,11 @@
|
||||
(gdb) target remote /dev/ttyS0
|
||||
</programlisting>
|
||||
<para>
|
||||
Example (kgdb to a terminal server):
|
||||
Example (kgdb to a terminal server on tcp port 2012):
|
||||
</para>
|
||||
<programlisting>
|
||||
% gdb ./vmlinux
|
||||
(gdb) target remote udp:192.168.2.2:6443
|
||||
</programlisting>
|
||||
<para>
|
||||
Example (kgdb over ethernet):
|
||||
</para>
|
||||
<programlisting>
|
||||
% gdb ./vmlinux
|
||||
(gdb) target remote udp:192.168.2.2:6443
|
||||
(gdb) target remote 192.168.2.2:2012
|
||||
</programlisting>
|
||||
<para>
|
||||
Once connected, you can debug a kernel the way you would debug an
|
||||
|
||||
@@ -327,6 +327,52 @@ Some people also put extra tags at the end. They'll just be ignored for
|
||||
now, but you can do this to mark internal company procedures or just
|
||||
point out some special detail about the sign-off.
|
||||
|
||||
If you are a subsystem or branch maintainer, sometimes you need to slightly
|
||||
modify patches you receive in order to merge them, because the code is not
|
||||
exactly the same in your tree and the submitters'. If you stick strictly to
|
||||
rule (c), you should ask the submitter to rediff, but this is a totally
|
||||
counter-productive waste of time and energy. Rule (b) allows you to adjust
|
||||
the code, but then it is very impolite to change one submitter's code and
|
||||
make him endorse your bugs. To solve this problem, it is recommended that
|
||||
you add a line between the last Signed-off-by header and yours, indicating
|
||||
the nature of your changes. While there is nothing mandatory about this, it
|
||||
seems like prepending the description with your mail and/or name, all
|
||||
enclosed in square brackets, is noticeable enough to make it obvious that
|
||||
you are responsible for last-minute changes. Example :
|
||||
|
||||
Signed-off-by: Random J Developer <random@developer.example.org>
|
||||
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
|
||||
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
|
||||
|
||||
This practise is particularly helpful if you maintain a stable branch and
|
||||
want at the same time to credit the author, track changes, merge the fix,
|
||||
and protect the submitter from complaints. Note that under no circumstances
|
||||
can you change the author's identity (the From header), as it is the one
|
||||
which appears in the changelog.
|
||||
|
||||
Special note to back-porters: It seems to be a common and useful practise
|
||||
to insert an indication of the origin of a patch at the top of the commit
|
||||
message (just after the subject line) to facilitate tracking. For instance,
|
||||
here's what we see in 2.6-stable :
|
||||
|
||||
Date: Tue May 13 19:10:30 2008 +0000
|
||||
|
||||
SCSI: libiscsi regression in 2.6.25: fix nop timer handling
|
||||
|
||||
commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
|
||||
|
||||
And here's what appears in 2.4 :
|
||||
|
||||
Date: Tue May 13 22:12:27 2008 +0200
|
||||
|
||||
wireless, airo: waitbusy() won't delay
|
||||
|
||||
[backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
|
||||
|
||||
Whatever the format, this information provides a valuable help to people
|
||||
tracking your trees, and to people trying to trouble-shoot bugs in your
|
||||
tree.
|
||||
|
||||
|
||||
13) When to use Acked-by: and Cc:
|
||||
|
||||
|
||||
@@ -21,6 +21,11 @@ This driver is known to work with the following cards:
|
||||
* SA E200
|
||||
* SA E200i
|
||||
* SA E500
|
||||
* SA P212
|
||||
* SA P410
|
||||
* SA P410i
|
||||
* SA P411
|
||||
* SA P812
|
||||
|
||||
Detecting drive failures:
|
||||
-------------------------
|
||||
|
||||
@@ -199,7 +199,7 @@ using the sched_setaffinity, mbind and set_mempolicy system calls.
|
||||
The following rules apply to each cpuset:
|
||||
|
||||
- Its CPUs and Memory Nodes must be a subset of its parents.
|
||||
- It can only be marked exclusive if its parent is.
|
||||
- It can't be marked exclusive unless its parent is.
|
||||
- If its cpu or memory is exclusive, they may not overlap any sibling.
|
||||
|
||||
These rules, and the natural hierarchy of cpusets, enable efficient
|
||||
@@ -345,7 +345,7 @@ is modified to perform an inline check for this PF_SPREAD_PAGE task
|
||||
flag, and if set, a call to a new routine cpuset_mem_spread_node()
|
||||
returns the node to prefer for the allocation.
|
||||
|
||||
Similarly, setting 'memory_spread_cache' turns on the flag
|
||||
Similarly, setting 'memory_spread_slab' turns on the flag
|
||||
PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
|
||||
pages from the node returned by cpuset_mem_spread_node().
|
||||
|
||||
@@ -542,7 +542,7 @@ otherwise initial value -1 that indicates the cpuset has no request.
|
||||
2 : search cores in a package.
|
||||
3 : search cpus in a node [= system wide on non-NUMA system]
|
||||
( 4 : search nodes in a chunk of node [on NUMA system] )
|
||||
( 5~ : search system wide [on NUMA system])
|
||||
( 5 : search system wide [on NUMA system] )
|
||||
|
||||
This file is per-cpuset and affect the sched domain where the cpuset
|
||||
belongs to. Therefore if the flag 'sched_load_balance' of a cpuset
|
||||
@@ -709,7 +709,10 @@ Now you want to do something with this cpuset.
|
||||
|
||||
In this directory you can find several files:
|
||||
# ls
|
||||
cpus cpu_exclusive mems mem_exclusive mem_hardwall tasks
|
||||
cpu_exclusive memory_migrate mems tasks
|
||||
cpus memory_pressure notify_on_release
|
||||
mem_exclusive memory_spread_page sched_load_balance
|
||||
mem_hardwall memory_spread_slab sched_relax_domain_level
|
||||
|
||||
Reading them will give you information about the state of this cpuset:
|
||||
the CPUs and Memory Nodes it can use, the processes that are using
|
||||
|
||||
@@ -139,8 +139,16 @@ commit=nrsec (*) Ext4 can be told to sync all its data and metadata
|
||||
Setting it to very large values will improve
|
||||
performance.
|
||||
|
||||
barrier=1 This enables/disables barriers. barrier=0 disables
|
||||
it, barrier=1 enables it.
|
||||
barrier=<0|1(*)> This enables/disables the use of write barriers in
|
||||
the jbd code. barrier=0 disables, barrier=1 enables.
|
||||
This also requires an IO stack which can support
|
||||
barriers, and if jbd gets an error on a barrier
|
||||
write, it will disable again with a warning.
|
||||
Write barriers enforce proper on-disk ordering
|
||||
of journal commits, making volatile disk write caches
|
||||
safe to use, at some performance penalty. If
|
||||
your disks are battery-backed in one way or another,
|
||||
disabling barriers may safely improve performance.
|
||||
|
||||
orlov (*) This enables the new Orlov block allocator. It is
|
||||
enabled by default.
|
||||
|
||||
@@ -36,6 +36,7 @@ files, each with their own function.
|
||||
local_cpus nearby CPU mask (cpumask, ro)
|
||||
resource PCI resource host addresses (ascii, ro)
|
||||
resource0..N PCI resource N, if present (binary, mmap)
|
||||
resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap)
|
||||
rom PCI ROM resource, if present (binary, ro)
|
||||
subsystem_device PCI subsystem device (ascii, ro)
|
||||
subsystem_vendor PCI subsystem vendor (ascii, ro)
|
||||
|
||||
@@ -2,17 +2,12 @@ Naming and data format standards for sysfs files
|
||||
------------------------------------------------
|
||||
|
||||
The libsensors library offers an interface to the raw sensors data
|
||||
through the sysfs interface. See libsensors documentation and source for
|
||||
further information. As of writing this document, libsensors
|
||||
(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating
|
||||
support for any given chip requires modifying the library's code.
|
||||
This is because libsensors was written for the procfs interface
|
||||
older kernel modules were using, which wasn't standardized enough.
|
||||
Recent versions of libsensors (from lm_sensors 2.8.2 and later) have
|
||||
support for the sysfs interface, though.
|
||||
|
||||
The new sysfs interface was designed to be as chip-independent as
|
||||
possible.
|
||||
through the sysfs interface. Since lm-sensors 3.0.0, libsensors is
|
||||
completely chip-independent. It assumes that all the kernel drivers
|
||||
implement the standard sysfs interface described in this document.
|
||||
This makes adding or updating support for any given chip very easy, as
|
||||
libsensors, and applications using it, do not need to be modified.
|
||||
This is a major improvement compared to lm-sensors 2.
|
||||
|
||||
Note that motherboards vary widely in the connections to sensor chips.
|
||||
There is no standard that ensures, for example, that the second
|
||||
@@ -35,19 +30,17 @@ access this data in a simple and consistent way. That said, such programs
|
||||
will have to implement conversion, labeling and hiding of inputs. For
|
||||
this reason, it is still not recommended to bypass the library.
|
||||
|
||||
If you are developing a userspace application please send us feedback on
|
||||
this standard.
|
||||
|
||||
Note that this standard isn't completely established yet, so it is subject
|
||||
to changes. If you are writing a new hardware monitoring driver those
|
||||
features can't seem to fit in this interface, please contact us with your
|
||||
extension proposal. Keep in mind that backward compatibility must be
|
||||
preserved.
|
||||
|
||||
Each chip gets its own directory in the sysfs /sys/devices tree. To
|
||||
find all sensor chips, it is easier to follow the device symlinks from
|
||||
/sys/class/hwmon/hwmon*.
|
||||
|
||||
Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes
|
||||
in the "physical" device directory. Since lm-sensors 3.0.1, attributes found
|
||||
in the hwmon "class" device directory are also supported. Complex drivers
|
||||
(e.g. drivers for multifunction chips) may want to use this possibility to
|
||||
avoid namespace pollution. The only drawback will be that older versions of
|
||||
libsensors won't support the driver in question.
|
||||
|
||||
All sysfs values are fixed point numbers.
|
||||
|
||||
There is only one value per file, unlike the older /proc specification.
|
||||
|
||||
@@ -1,6 +1,105 @@
|
||||
kernel-doc nano-HOWTO
|
||||
=====================
|
||||
|
||||
How to format kernel-doc comments
|
||||
---------------------------------
|
||||
|
||||
In order to provide embedded, 'C' friendly, easy to maintain,
|
||||
but consistent and extractable documentation of the functions and
|
||||
data structures in the Linux kernel, the Linux kernel has adopted
|
||||
a consistent style for documenting functions and their parameters,
|
||||
and structures and their members.
|
||||
|
||||
The format for this documentation is called the kernel-doc format.
|
||||
It is documented in this Documentation/kernel-doc-nano-HOWTO.txt file.
|
||||
|
||||
This style embeds the documentation within the source files, using
|
||||
a few simple conventions. The scripts/kernel-doc perl script, some
|
||||
SGML templates in Documentation/DocBook, and other tools understand
|
||||
these conventions, and are used to extract this embedded documentation
|
||||
into various documents.
|
||||
|
||||
In order to provide good documentation of kernel functions and data
|
||||
structures, please use the following conventions to format your
|
||||
kernel-doc comments in Linux kernel source.
|
||||
|
||||
We definitely need kernel-doc formatted documentation for functions
|
||||
that are exported to loadable modules using EXPORT_SYMBOL.
|
||||
|
||||
We also look to provide kernel-doc formatted documentation for
|
||||
functions externally visible to other kernel files (not marked
|
||||
"static").
|
||||
|
||||
We also recommend providing kernel-doc formatted documentation
|
||||
for private (file "static") routines, for consistency of kernel
|
||||
source code layout. But this is lower priority and at the
|
||||
discretion of the MAINTAINER of that kernel source file.
|
||||
|
||||
Data structures visible in kernel include files should also be
|
||||
documented using kernel-doc formatted comments.
|
||||
|
||||
The opening comment mark "/**" is reserved for kernel-doc comments.
|
||||
Only comments so marked will be considered by the kernel-doc scripts,
|
||||
and any comment so marked must be in kernel-doc format. Do not use
|
||||
"/**" to be begin a comment block unless the comment block contains
|
||||
kernel-doc formatted comments. The closing comment marker for
|
||||
kernel-doc comments can be either "*/" or "**/".
|
||||
|
||||
Kernel-doc comments should be placed just before the function
|
||||
or data structure being described.
|
||||
|
||||
Example kernel-doc function comment:
|
||||
|
||||
/**
|
||||
* foobar() - short function description of foobar
|
||||
* @arg1: Describe the first argument to foobar.
|
||||
* @arg2: Describe the second argument to foobar.
|
||||
* One can provide multiple line descriptions
|
||||
* for arguments.
|
||||
*
|
||||
* A longer description, with more discussion of the function foobar()
|
||||
* that might be useful to those using or modifying it. Begins with
|
||||
* empty comment line, and may include additional embedded empty
|
||||
* comment lines.
|
||||
*
|
||||
* The longer description can have multiple paragraphs.
|
||||
**/
|
||||
|
||||
The first line, with the short description, must be on a single line.
|
||||
|
||||
The @argument descriptions must begin on the very next line following
|
||||
this opening short function description line, with no intervening
|
||||
empty comment lines.
|
||||
|
||||
Example kernel-doc data structure comment.
|
||||
|
||||
/**
|
||||
* struct blah - the basic blah structure
|
||||
* @mem1: describe the first member of struct blah
|
||||
* @mem2: describe the second member of struct blah,
|
||||
* perhaps with more lines and words.
|
||||
*
|
||||
* Longer description of this structure.
|
||||
**/
|
||||
|
||||
The kernel-doc function comments describe each parameter to the
|
||||
function, in order, with the @name lines.
|
||||
|
||||
The kernel-doc data structure comments describe each structure member
|
||||
in the data structure, with the @name lines.
|
||||
|
||||
The longer description formatting is "reflowed", losing your line
|
||||
breaks. So presenting carefully formatted lists within these
|
||||
descriptions won't work so well; derived documentation will lose
|
||||
the formatting.
|
||||
|
||||
See the section below "How to add extractable documentation to your
|
||||
source files" for more details and notes on how to format kernel-doc
|
||||
comments.
|
||||
|
||||
Components of the kernel-doc system
|
||||
-----------------------------------
|
||||
|
||||
Many places in the source tree have extractable documentation in the
|
||||
form of block comments above functions. The components of this system
|
||||
are:
|
||||
|
||||
@@ -715,14 +715,14 @@
|
||||
|
||||
* Name: "Gary's Encyclopedia - The Linux Kernel"
|
||||
Author: Gary (I suppose...).
|
||||
URL: http://www.lisoleg.net/cgi-bin/lisoleg.pl?view=kernel.htm
|
||||
Keywords: links, not found here?.
|
||||
URL: http://slencyclopedia.berlios.de/index.html
|
||||
Keywords: linux, community, everything!
|
||||
Description: Gary's Encyclopedia exists to allow the rapid finding
|
||||
of documentation and other information of interest to GNU/Linux
|
||||
users. It has about 4000 links to external pages in 150 major
|
||||
categories. This link is for kernel-specific links, documents,
|
||||
sites... Look there if you could not find here what you were
|
||||
looking for.
|
||||
sites... This list is now hosted by developer.Berlios.de,
|
||||
but seems not to have been updated since sometime in 1999.
|
||||
|
||||
* Name: "The home page of Linux-MM"
|
||||
Author: The Linux-MM team.
|
||||
|
||||
@@ -305,7 +305,7 @@ should not be manipulated by any other user.
|
||||
|
||||
A kset keeps its children in a standard kernel linked list. Kobjects point
|
||||
back to their containing kset via their kset field. In almost all cases,
|
||||
the kobjects belonging to a ket have that kset (or, strictly, its embedded
|
||||
the kobjects belonging to a kset have that kset (or, strictly, its embedded
|
||||
kobject) in their parent.
|
||||
|
||||
As a kset contains a kobject within it, it should always be dynamically
|
||||
|
||||
@@ -503,7 +503,7 @@ generate input device EV_KEY events.
|
||||
In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW
|
||||
events for switches:
|
||||
|
||||
SW_RADIO T60 and later hardare rfkill rocker switch
|
||||
SW_RFKILL_ALL T60 and later hardare rfkill rocker switch
|
||||
SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A
|
||||
|
||||
Non hot-key ACPI HKEY event map:
|
||||
|
||||
@@ -157,6 +157,9 @@ struct virtqueue
|
||||
|
||||
/* The routine to call when the Guest pings us. */
|
||||
void (*handle_output)(int fd, struct virtqueue *me);
|
||||
|
||||
/* Outstanding buffers */
|
||||
unsigned int inflight;
|
||||
};
|
||||
|
||||
/* Remember the arguments to the program so we can "reboot" */
|
||||
@@ -702,6 +705,7 @@ static unsigned get_vq_desc(struct virtqueue *vq,
|
||||
errx(1, "Looped descriptor");
|
||||
} while ((i = next_desc(vq, i)) != vq->vring.num);
|
||||
|
||||
vq->inflight++;
|
||||
return head;
|
||||
}
|
||||
|
||||
@@ -719,6 +723,7 @@ static void add_used(struct virtqueue *vq, unsigned int head, int len)
|
||||
/* Make sure buffer is written before we update index. */
|
||||
wmb();
|
||||
vq->vring.used->idx++;
|
||||
vq->inflight--;
|
||||
}
|
||||
|
||||
/* This actually sends the interrupt for this virtqueue */
|
||||
@@ -726,8 +731,9 @@ static void trigger_irq(int fd, struct virtqueue *vq)
|
||||
{
|
||||
unsigned long buf[] = { LHREQ_IRQ, vq->config.irq };
|
||||
|
||||
/* If they don't want an interrupt, don't send one. */
|
||||
if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
|
||||
/* If they don't want an interrupt, don't send one, unless empty. */
|
||||
if ((vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
|
||||
&& vq->inflight)
|
||||
return;
|
||||
|
||||
/* Send the Guest an interrupt tell them we used something up. */
|
||||
@@ -1107,6 +1113,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
|
||||
vq->next = NULL;
|
||||
vq->last_avail_idx = 0;
|
||||
vq->dev = dev;
|
||||
vq->inflight = 0;
|
||||
|
||||
/* Initialize the configuration. */
|
||||
vq->config.num = num_descs;
|
||||
@@ -1368,6 +1375,7 @@ static void setup_tun_net(const char *arg)
|
||||
|
||||
/* Tell Guest what MAC address to use. */
|
||||
add_feature(dev, VIRTIO_NET_F_MAC);
|
||||
add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
|
||||
set_config(dev, sizeof(conf), &conf);
|
||||
|
||||
/* We don't need the socket any more; setup is done. */
|
||||
|
||||
@@ -46,7 +46,7 @@ These are the ARCnet drivers for Linux.
|
||||
|
||||
|
||||
This new release (2.91) has been put together by David Woodhouse
|
||||
<dwmw2@cam.ac.uk>, in an attempt to tidy up the driver after adding support
|
||||
<dwmw2@infradead.org>, in an attempt to tidy up the driver after adding support
|
||||
for yet another chipset. Now the generic support has been separated from the
|
||||
individual chipset drivers, and the source files aren't quite so packed with
|
||||
#ifdefs! I've changed this file a bit, but kept it in the first person from
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
In order to use the Ethernet bridging functionality, you'll need the
|
||||
userspace tools. These programs and documentation are available
|
||||
at http://bridge.sourceforge.net. The download page is
|
||||
at http://www.linux-foundation.org/en/Net:Bridge. The download page is
|
||||
http://prdownloads.sourceforge.net/bridge.
|
||||
|
||||
If you still have questions, don't hesitate to post to the mailing list
|
||||
|
||||
@@ -60,7 +60,7 @@
|
||||
59 -> DViCO FusionHDTV 5 PCI nano [18ac:d530]
|
||||
60 -> Pinnacle Hybrid PCTV [12ab:1788]
|
||||
61 -> Winfast TV2000 XP Global [107d:6f18]
|
||||
62 -> PowerColor Real Angel 330 [14f1:ea3d]
|
||||
62 -> PowerColor RA330 [14f1:ea3d]
|
||||
63 -> Geniatech X8000-MT DVBT [14f1:8852]
|
||||
64 -> DViCO FusionHDTV DVB-T PRO [18ac:db30]
|
||||
65 -> DViCO FusionHDTV 7 Gold [18ac:d610]
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
Some notes regarding the cx18 driver for the Conexant CX23418 MPEG
|
||||
encoder chip:
|
||||
|
||||
1) The only hardware currently supported is the Hauppauge HVR-1600.
|
||||
1) The only hardware currently supported is the Hauppauge HVR-1600
|
||||
card and the Compro VideoMate H900 (note that this card only
|
||||
supports analog input, it has no digital tuner!).
|
||||
|
||||
2) Some people have problems getting the i2c bus to work. Cause unknown.
|
||||
The symptom is that the eeprom cannot be read and the card is
|
||||
|
||||
@@ -0,0 +1,77 @@
|
||||
pagemap, from the userspace perspective
|
||||
---------------------------------------
|
||||
|
||||
pagemap is a new (as of 2.6.25) set of interfaces in the kernel that allow
|
||||
userspace programs to examine the page tables and related information by
|
||||
reading files in /proc.
|
||||
|
||||
There are three components to pagemap:
|
||||
|
||||
* /proc/pid/pagemap. This file lets a userspace process find out which
|
||||
physical frame each virtual page is mapped to. It contains one 64-bit
|
||||
value for each virtual page, containing the following data (from
|
||||
fs/proc/task_mmu.c, above pagemap_read):
|
||||
|
||||
* Bits 0-55 page frame number (PFN) if present
|
||||
* Bits 0-4 swap type if swapped
|
||||
* Bits 5-55 swap offset if swapped
|
||||
* Bits 55-60 page shift (page size = 1<<page shift)
|
||||
* Bit 61 reserved for future use
|
||||
* Bit 62 page swapped
|
||||
* Bit 63 page present
|
||||
|
||||
If the page is not present but in swap, then the PFN contains an
|
||||
encoding of the swap file number and the page's offset into the
|
||||
swap. Unmapped pages return a null PFN. This allows determining
|
||||
precisely which pages are mapped (or in swap) and comparing mapped
|
||||
pages between processes.
|
||||
|
||||
Efficient users of this interface will use /proc/pid/maps to
|
||||
determine which areas of memory are actually mapped and llseek to
|
||||
skip over unmapped regions.
|
||||
|
||||
* /proc/kpagecount. This file contains a 64-bit count of the number of
|
||||
times each page is mapped, indexed by PFN.
|
||||
|
||||
* /proc/kpageflags. This file contains a 64-bit set of flags for each
|
||||
page, indexed by PFN.
|
||||
|
||||
The flags are (from fs/proc/proc_misc, above kpageflags_read):
|
||||
|
||||
0. LOCKED
|
||||
1. ERROR
|
||||
2. REFERENCED
|
||||
3. UPTODATE
|
||||
4. DIRTY
|
||||
5. LRU
|
||||
6. ACTIVE
|
||||
7. SLAB
|
||||
8. WRITEBACK
|
||||
9. RECLAIM
|
||||
10. BUDDY
|
||||
|
||||
Using pagemap to do something useful:
|
||||
|
||||
The general procedure for using pagemap to find out about a process' memory
|
||||
usage goes like this:
|
||||
|
||||
1. Read /proc/pid/maps to determine which parts of the memory space are
|
||||
mapped to what.
|
||||
2. Select the maps you are interested in -- all of them, or a particular
|
||||
library, or the stack or the heap, etc.
|
||||
3. Open /proc/pid/pagemap and seek to the pages you would like to examine.
|
||||
4. Read a u64 for each page from pagemap.
|
||||
5. Open /proc/kpagecount and/or /proc/kpageflags. For each PFN you just
|
||||
read, seek to that entry in the file, and read the data you want.
|
||||
|
||||
For example, to find the "unique set size" (USS), which is the amount of
|
||||
memory that a process is using that is not shared with any other process,
|
||||
you can go through every map in the process, find the PFNs, look those up
|
||||
in kpagecount, and tally up the number of pages that are only referenced
|
||||
once.
|
||||
|
||||
Other notes:
|
||||
|
||||
Reading from any of the files will return -EINVAL if you are not starting
|
||||
the read on an 8-byte boundary (e.g., if you seeked an odd number of bytes
|
||||
into the file), or if the size of the read is not a multiple of 8 bytes.
|
||||
+24
-32
@@ -228,21 +228,21 @@ ACPI BATTERY DRIVERS
|
||||
P: Alexey Starikovskiy
|
||||
M: astarikovskiy@suse.de
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://acpi.sourceforge.net/
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Supported
|
||||
|
||||
ACPI EC DRIVER
|
||||
P: Alexey Starikovskiy
|
||||
M: astarikovskiy@suse.de
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://acpi.sourceforge.net/
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Supported
|
||||
|
||||
ACPI FAN DRIVER
|
||||
P: Len Brown
|
||||
M: len.brown@intel.com
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://acpi.sourceforge.net/
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Supported
|
||||
|
||||
ACPI PCI HOTPLUG DRIVER
|
||||
@@ -255,14 +255,14 @@ ACPI THERMAL DRIVER
|
||||
P: Len Brown
|
||||
M: len.brown@intel.com
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://acpi.sourceforge.net/
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Supported
|
||||
|
||||
ACPI VIDEO DRIVER
|
||||
P: Rui Zhang
|
||||
M: rui.zhang@intel.com
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://acpi.sourceforge.net/
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Supported
|
||||
|
||||
ACPI WMI DRIVER
|
||||
@@ -274,7 +274,7 @@ S: Maintained
|
||||
|
||||
AD1889 ALSA SOUND DRIVER
|
||||
P: Kyle McMartin
|
||||
M: kyle@parisc-linux.org
|
||||
M: kyle@mcmartin.ca
|
||||
P: Thibaut Varene
|
||||
M: T-Bone@parisc-linux.org
|
||||
W: http://wiki.parisc-linux.org/AD1889
|
||||
@@ -995,8 +995,8 @@ L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER
|
||||
P: Eliezer Tamir
|
||||
M: eliezert@broadcom.com
|
||||
P: Eilon Greenstein
|
||||
M: eilong@broadcom.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
@@ -1202,6 +1202,7 @@ M: pj@sgi.com
|
||||
M: menage@google.com
|
||||
L: linux-kernel@vger.kernel.org
|
||||
W: http://www.bullopensource.org/cpuset/
|
||||
W: http://oss.sgi.com/projects/cpusets/
|
||||
S: Supported
|
||||
|
||||
CRAMFS FILESYSTEM
|
||||
@@ -1611,7 +1612,7 @@ ETHERNET BRIDGE
|
||||
P: Stephen Hemminger
|
||||
M: shemminger@linux-foundation.org
|
||||
L: bridge@lists.linux-foundation.org
|
||||
W: http://bridge.sourceforge.net/
|
||||
W: http://www.linux-foundation.org/en/Net:Bridge
|
||||
S: Maintained
|
||||
|
||||
ETHERTEAM 16I DRIVER
|
||||
@@ -1827,7 +1828,7 @@ S: Maintained
|
||||
|
||||
HARMONY SOUND DRIVER
|
||||
P: Kyle McMartin
|
||||
M: kyle@parisc-linux.org
|
||||
M: kyle@mcmartin.ca
|
||||
L: linux-parisc@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
@@ -2565,7 +2566,6 @@ LINUX SECURITY MODULE (LSM) FRAMEWORK
|
||||
P: Chris Wright
|
||||
M: chrisw@sous-sol.org
|
||||
L: linux-security-module@vger.kernel.org
|
||||
W: http://lsm.immunix.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/chrisw/lsm-2.6.git
|
||||
S: Supported
|
||||
|
||||
@@ -2866,8 +2866,8 @@ S: Maintained
|
||||
NETEFFECT IWARP RNIC DRIVER (IW_NES)
|
||||
P: Faisal Latif
|
||||
M: flatif@neteffect.com
|
||||
P: Nishi Gupta
|
||||
M: ngupta@neteffect.com
|
||||
P: Chien Tung
|
||||
M: ctung@neteffect.com
|
||||
P: Glenn Streiff
|
||||
M: gstreiff@neteffect.com
|
||||
L: general@lists.openfabrics.org
|
||||
@@ -3121,7 +3121,7 @@ S: Maintained
|
||||
|
||||
PARISC ARCHITECTURE
|
||||
P: Kyle McMartin
|
||||
M: kyle@parisc-linux.org
|
||||
M: kyle@mcmartin.ca
|
||||
P: Matthew Wilcox
|
||||
M: matthew@wil.cx
|
||||
P: Grant Grundler
|
||||
@@ -3265,7 +3265,7 @@ S: Maintained
|
||||
|
||||
PPP OVER ETHERNET
|
||||
P: Michal Ostrowski
|
||||
M: mostrows@speakeasy.net
|
||||
M: mostrows@earthlink.net
|
||||
S: Maintained
|
||||
|
||||
PPP OVER L2TP
|
||||
@@ -3330,9 +3330,11 @@ L: video4linux-list@redhat.com
|
||||
W: http://www.isely.net/pvrusb2/
|
||||
S: Maintained
|
||||
|
||||
PXA2xx SUPPORT
|
||||
P: Nicolas Pitre
|
||||
M: nico@cam.org
|
||||
PXA2xx/PXA3xx SUPPORT
|
||||
P: Eric Miao
|
||||
M: eric.miao@marvell.com
|
||||
P: Russell King
|
||||
M: linux@arm.linux.org.uk
|
||||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
@@ -3439,10 +3441,7 @@ L: rtc-linux@googlegroups.com
|
||||
S: Maintained
|
||||
|
||||
REISERFS FILE SYSTEM
|
||||
P: Hans Reiser
|
||||
M: reiserfs-dev@namesys.com
|
||||
L: reiserfs-devel@vger.kernel.org
|
||||
W: http://www.namesys.com
|
||||
S: Supported
|
||||
|
||||
RFKILL
|
||||
@@ -3662,13 +3661,6 @@ M: romieu@fr.zoreil.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
SIS 5513 IDE CONTROLLER DRIVER
|
||||
P: Lionel Bouton
|
||||
M: Lionel.Bouton@inet6.fr
|
||||
W: http://inet6.dyn.dhs.org/sponsoring/sis5513/index.html
|
||||
W: http://gyver.homeip.net/sis5513/index.html
|
||||
S: Maintained
|
||||
|
||||
SIS 900/7016 FAST ETHERNET DRIVER
|
||||
P: Daniele Venzano
|
||||
M: venza@brownhat.org
|
||||
@@ -4034,7 +4026,7 @@ TULIP NETWORK DRIVERS
|
||||
P: Grant Grundler
|
||||
M: grundler@parisc-linux.org
|
||||
P: Kyle McMartin
|
||||
M: kyle@parisc-linux.org
|
||||
M: kyle@mcmartin.ca
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
@@ -4439,10 +4431,10 @@ M: johnpol@2ka.mipt.ru
|
||||
S: Maintained
|
||||
|
||||
W83791D HARDWARE MONITORING DRIVER
|
||||
P: Charles Spirakis
|
||||
M: bezaur@gmail.com
|
||||
P: Marc Hulsman
|
||||
M: m.hulsman@tudelft.nl
|
||||
L: lm-sensors@lm-sensors.org
|
||||
S: Odd Fixes
|
||||
S: Maintained
|
||||
|
||||
W83793 HARDWARE MONITORING DRIVER
|
||||
P: Rudolf Marek
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 26
|
||||
EXTRAVERSION = -rc3
|
||||
NAME = Funky Weasel is Jiggy wit it
|
||||
EXTRAVERSION = -rc8
|
||||
NAME = Rotary Wombat
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user