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 'linux-2.6' into for-2.6.24
This commit is contained in:
Paul Mackerras
@@ -316,7 +316,8 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags)
|
||||
|
||||
<chapter id="pubfunctions">
|
||||
<title>Public Functions Provided</title>
|
||||
!Einclude/asm-i386/io.h
|
||||
!Iinclude/asm-i386/io.h
|
||||
!Elib/iomap.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
||||
+2
-2
@@ -208,7 +208,7 @@ tools. One such tool that is particularly recommended is the Linux
|
||||
Cross-Reference project, which is able to present source code in a
|
||||
self-referential, indexed webpage format. An excellent up-to-date
|
||||
repository of the kernel code may be found at:
|
||||
http://sosdg.org/~coywolf/lxr/
|
||||
http://users.sosdg.org/~qiyong/lxr/
|
||||
|
||||
|
||||
The development process
|
||||
@@ -384,7 +384,7 @@ One of the best ways to put into practice your hacking skills is by fixing
|
||||
bugs reported by other people. Not only you will help to make the kernel
|
||||
more stable, you'll learn to fix real world problems and you will improve
|
||||
your skills, and other developers will be aware of your presence. Fixing
|
||||
bugs is one of the best ways to earn merit amongst the developers, because
|
||||
bugs is one of the best ways to get merits among other developers, because
|
||||
not many people like wasting time fixing other people's bugs.
|
||||
|
||||
To work in the already reported bug reports, go to http://bugzilla.kernel.org.
|
||||
|
||||
@@ -560,7 +560,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
||||
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
|
||||
|
||||
Kernel Documentation/CodingStyle:
|
||||
<http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>
|
||||
<http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
|
||||
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<http://lkml.org/lkml/2005/4/7/183>
|
||||
|
||||
@@ -196,7 +196,7 @@ void print_delayacct(struct taskstats *t)
|
||||
"IO %15s%15s\n"
|
||||
" %15llu%15llu\n"
|
||||
"MEM %15s%15s\n"
|
||||
" %15llu%15llu\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,
|
||||
|
||||
@@ -111,21 +111,21 @@ sub tda10045 {
|
||||
}
|
||||
|
||||
sub tda10046 {
|
||||
my $sourcefile = "tt_budget_217g.zip";
|
||||
my $url = "http://www.technotrend.de/new/217g/$sourcefile";
|
||||
my $hash = "6a7e1e2f2644b162ff0502367553c72d";
|
||||
my $outfile = "dvb-fe-tda10046.fw";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
|
||||
my $sourcefile = "TT_PCI_2.19h_28_11_2006.zip";
|
||||
my $url = "http://technotrend-online.com/download/software/219/$sourcefile";
|
||||
my $hash = "6a7e1e2f2644b162ff0502367553c72d";
|
||||
my $outfile = "dvb-fe-tda10046.fw";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
|
||||
|
||||
checkstandard();
|
||||
checkstandard();
|
||||
|
||||
wgetfile($sourcefile, $url);
|
||||
unzip($sourcefile, $tmpdir);
|
||||
extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478, "$tmpdir/fwtmp");
|
||||
verify("$tmpdir/fwtmp", $hash);
|
||||
copy("$tmpdir/fwtmp", $outfile);
|
||||
wgetfile($sourcefile, $url);
|
||||
unzip($sourcefile, $tmpdir);
|
||||
extract("$tmpdir/TT_PCI_2.19h_28_11_2006/software/OEM/PCI/App/ttlcdacc.dll", 0x65389, 24478, "$tmpdir/fwtmp");
|
||||
verify("$tmpdir/fwtmp", $hash);
|
||||
copy("$tmpdir/fwtmp", $outfile);
|
||||
|
||||
$outfile;
|
||||
$outfile;
|
||||
}
|
||||
|
||||
sub tda10046lifeview {
|
||||
|
||||
@@ -197,6 +197,14 @@ Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/acpi/event
|
||||
When: February 2008
|
||||
Why: /proc/acpi/event has been replaced by events via the input layer
|
||||
and netlink since 2.6.23.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Compaq touchscreen device emulation
|
||||
When: Oct 2007
|
||||
Files: drivers/input/tsdev.c
|
||||
|
||||
@@ -6,12 +6,26 @@ ABOUT
|
||||
|
||||
v9fs is a Unix implementation of the Plan 9 9p remote filesystem protocol.
|
||||
|
||||
This software was originally developed by Ron Minnich <rminnich@lanl.gov>
|
||||
and Maya Gokhale <maya@lanl.gov>. Additional development by Greg Watson
|
||||
This software was originally developed by Ron Minnich <rminnich@sandia.gov>
|
||||
and Maya Gokhale. Additional development by Greg Watson
|
||||
<gwatson@lanl.gov> and most recently Eric Van Hensbergen
|
||||
<ericvh@gmail.com>, Latchesar Ionkov <lucho@ionkov.net> and Russ Cox
|
||||
<rsc@swtch.com>.
|
||||
|
||||
The best detailed explanation of the Linux implementation and applications of
|
||||
the 9p client is available in the form of a USENIX paper:
|
||||
http://www.usenix.org/events/usenix05/tech/freenix/hensbergen.html
|
||||
|
||||
Other applications are described in the following papers:
|
||||
* XCPU & Clustering
|
||||
http://www.xcpu.org/xcpu-talk.pdf
|
||||
* KVMFS: control file system for KVM
|
||||
http://www.xcpu.org/kvmfs.pdf
|
||||
* CellFS: A New ProgrammingModel for the Cell BE
|
||||
http://www.xcpu.org/cellfs-talk.pdf
|
||||
* PROSE I/O: Using 9p to enable Application Partitions
|
||||
http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
|
||||
|
||||
USAGE
|
||||
=====
|
||||
|
||||
@@ -90,9 +104,9 @@ subset of the namespace by extending the path: '#U*'/tmp would just export
|
||||
and export.
|
||||
|
||||
A Linux version of the 9p server is now maintained under the npfs project
|
||||
on sourceforge (http://sourceforge.net/projects/npfs). There is also a
|
||||
more stable single-threaded version of the server (named spfs) available from
|
||||
the same CVS repository.
|
||||
on sourceforge (http://sourceforge.net/projects/npfs). The currently
|
||||
maintained version is the single-threaded version of the server (named spfs)
|
||||
available from the same CVS repository.
|
||||
|
||||
There are user and developer mailing lists available through the v9fs project
|
||||
on sourceforge (http://sourceforge.net/projects/v9fs).
|
||||
|
||||
@@ -952,14 +952,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Format: <1-256>
|
||||
|
||||
maxcpus= [SMP] Maximum number of processors that an SMP kernel
|
||||
should make use of.
|
||||
Using "nosmp" or "maxcpus=0" will disable SMP
|
||||
entirely (the MPS table probe still happens, though).
|
||||
A command-line option of "maxcpus=<NUM>", where <NUM>
|
||||
is an integer greater than 0, limits the maximum number
|
||||
of CPUs activated in SMP mode to <NUM>.
|
||||
Using "maxcpus=1" on an SMP kernel is the trivial
|
||||
case of an SMP kernel with only one CPU.
|
||||
should make use of. maxcpus=n : n >= 0 limits the
|
||||
kernel to using 'n' processors. n=0 is a special case,
|
||||
it is equivalent to "nosmp", which also disables
|
||||
the IO APIC.
|
||||
|
||||
max_addr=[KMG] [KNL,BOOT,ia64] All physical memory greater than or
|
||||
equal to this physical address is ignored.
|
||||
@@ -1184,7 +1180,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
nosep [BUGS=X86-32] Disables x86 SYSENTER/SYSEXIT support.
|
||||
|
||||
nosmp [SMP] Tells an SMP kernel to act as a UP kernel.
|
||||
nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
|
||||
and disable the IO APIC. legacy for "maxcpus=0".
|
||||
|
||||
nosoftlockup [KNL] Disable the soft-lockup detector.
|
||||
|
||||
@@ -1826,6 +1823,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
-1: disable all active trip points in all thermal zones
|
||||
<degrees C>: override all lowest active trip points
|
||||
|
||||
thermal.crt= [HW,ACPI]
|
||||
-1: disable all critical trip points in all thermal zones
|
||||
<degrees C>: lower all critical trip points
|
||||
|
||||
thermal.nocrt= [HW,ACPI]
|
||||
Set to disable actions on ACPI thermal zone
|
||||
critical and hot trip points.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,332 @@
|
||||
|
||||
What is Linux Memory Policy?
|
||||
|
||||
In the Linux kernel, "memory policy" determines from which node the kernel will
|
||||
allocate memory in a NUMA system or in an emulated NUMA system. Linux has
|
||||
supported platforms with Non-Uniform Memory Access architectures since 2.4.?.
|
||||
The current memory policy support was added to Linux 2.6 around May 2004. This
|
||||
document attempts to describe the concepts and APIs of the 2.6 memory policy
|
||||
support.
|
||||
|
||||
Memory policies should not be confused with cpusets (Documentation/cpusets.txt)
|
||||
which is an administrative mechanism for restricting the nodes from which
|
||||
memory may be allocated by a set of processes. Memory policies are a
|
||||
programming interface that a NUMA-aware application can take advantage of. When
|
||||
both cpusets and policies are applied to a task, the restrictions of the cpuset
|
||||
takes priority. See "MEMORY POLICIES AND CPUSETS" below for more details.
|
||||
|
||||
MEMORY POLICY CONCEPTS
|
||||
|
||||
Scope of Memory Policies
|
||||
|
||||
The Linux kernel supports _scopes_ of memory policy, described here from
|
||||
most general to most specific:
|
||||
|
||||
System Default Policy: this policy is "hard coded" into the kernel. It
|
||||
is the policy that governs all page allocations that aren't controlled
|
||||
by one of the more specific policy scopes discussed below. When the
|
||||
system is "up and running", the system default policy will use "local
|
||||
allocation" described below. However, during boot up, the system
|
||||
default policy will be set to interleave allocations across all nodes
|
||||
with "sufficient" memory, so as not to overload the initial boot node
|
||||
with boot-time allocations.
|
||||
|
||||
Task/Process Policy: this is an optional, per-task policy. When defined
|
||||
for a specific task, this policy controls all page allocations made by or
|
||||
on behalf of the task that aren't controlled by a more specific scope.
|
||||
If a task does not define a task policy, then all page allocations that
|
||||
would have been controlled by the task policy "fall back" to the System
|
||||
Default Policy.
|
||||
|
||||
The task policy applies to the entire address space of a task. Thus,
|
||||
it is inheritable, and indeed is inherited, across both fork()
|
||||
[clone() w/o the CLONE_VM flag] and exec*(). This allows a parent task
|
||||
to establish the task policy for a child task exec()'d from an
|
||||
executable image that has no awareness of memory policy. See the
|
||||
MEMORY POLICY APIS section, below, for an overview of the system call
|
||||
that a task may use to set/change it's task/process policy.
|
||||
|
||||
In a multi-threaded task, task policies apply only to the thread
|
||||
[Linux kernel task] that installs the policy and any threads
|
||||
subsequently created by that thread. Any sibling threads existing
|
||||
at the time a new task policy is installed retain their current
|
||||
policy.
|
||||
|
||||
A task policy applies only to pages allocated after the policy is
|
||||
installed. Any pages already faulted in by the task when the task
|
||||
changes its task policy remain where they were allocated based on
|
||||
the policy at the time they were allocated.
|
||||
|
||||
VMA Policy: A "VMA" or "Virtual Memory Area" refers to a range of a task's
|
||||
virtual adddress space. A task may define a specific policy for a range
|
||||
of its virtual address space. See the MEMORY POLICIES APIS section,
|
||||
below, for an overview of the mbind() system call used to set a VMA
|
||||
policy.
|
||||
|
||||
A VMA policy will govern the allocation of pages that back this region of
|
||||
the address space. Any regions of the task's address space that don't
|
||||
have an explicit VMA policy will fall back to the task policy, which may
|
||||
itself fall back to the System Default Policy.
|
||||
|
||||
VMA policies have a few complicating details:
|
||||
|
||||
VMA policy applies ONLY to anonymous pages. These include pages
|
||||
allocated for anonymous segments, such as the task stack and heap, and
|
||||
any regions of the address space mmap()ed with the MAP_ANONYMOUS flag.
|
||||
If a VMA policy is applied to a file mapping, it will be ignored if
|
||||
the mapping used the MAP_SHARED flag. If the file mapping used the
|
||||
MAP_PRIVATE flag, the VMA policy will only be applied when an
|
||||
anonymous page is allocated on an attempt to write to the mapping--
|
||||
i.e., at Copy-On-Write.
|
||||
|
||||
VMA policies are shared between all tasks that share a virtual address
|
||||
space--a.k.a. threads--independent of when the policy is installed; and
|
||||
they are inherited across fork(). However, because VMA policies refer
|
||||
to a specific region of a task's address space, and because the address
|
||||
space is discarded and recreated on exec*(), VMA policies are NOT
|
||||
inheritable across exec(). Thus, only NUMA-aware applications may
|
||||
use VMA policies.
|
||||
|
||||
A task may install a new VMA policy on a sub-range of a previously
|
||||
mmap()ed region. When this happens, Linux splits the existing virtual
|
||||
memory area into 2 or 3 VMAs, each with it's own policy.
|
||||
|
||||
By default, VMA policy applies only to pages allocated after the policy
|
||||
is installed. Any pages already faulted into the VMA range remain
|
||||
where they were allocated based on the policy at the time they were
|
||||
allocated. However, since 2.6.16, Linux supports page migration via
|
||||
the mbind() system call, so that page contents can be moved to match
|
||||
a newly installed policy.
|
||||
|
||||
Shared Policy: Conceptually, shared policies apply to "memory objects"
|
||||
mapped shared into one or more tasks' distinct address spaces. An
|
||||
application installs a shared policies the same way as VMA policies--using
|
||||
the mbind() system call specifying a range of virtual addresses that map
|
||||
the shared object. However, unlike VMA policies, which can be considered
|
||||
to be an attribute of a range of a task's address space, shared policies
|
||||
apply directly to the shared object. Thus, all tasks that attach to the
|
||||
object share the policy, and all pages allocated for the shared object,
|
||||
by any task, will obey the shared policy.
|
||||
|
||||
As of 2.6.22, only shared memory segments, created by shmget() or
|
||||
mmap(MAP_ANONYMOUS|MAP_SHARED), support shared policy. When shared
|
||||
policy support was added to Linux, the associated data structures were
|
||||
added to hugetlbfs shmem segments. At the time, hugetlbfs did not
|
||||
support allocation at fault time--a.k.a lazy allocation--so hugetlbfs
|
||||
shmem segments were never "hooked up" to the shared policy support.
|
||||
Although hugetlbfs segments now support lazy allocation, their support
|
||||
for shared policy has not been completed.
|
||||
|
||||
As mentioned above [re: VMA policies], allocations of page cache
|
||||
pages for regular files mmap()ed with MAP_SHARED ignore any VMA
|
||||
policy installed on the virtual address range backed by the shared
|
||||
file mapping. Rather, shared page cache pages, including pages backing
|
||||
private mappings that have not yet been written by the task, follow
|
||||
task policy, if any, else System Default Policy.
|
||||
|
||||
The shared policy infrastructure supports different policies on subset
|
||||
ranges of the shared object. However, Linux still splits the VMA of
|
||||
the task that installs the policy for each range of distinct policy.
|
||||
Thus, different tasks that attach to a shared memory segment can have
|
||||
different VMA configurations mapping that one shared object. This
|
||||
can be seen by examining the /proc/<pid>/numa_maps of tasks sharing
|
||||
a shared memory region, when one task has installed shared policy on
|
||||
one or more ranges of the region.
|
||||
|
||||
Components of Memory Policies
|
||||
|
||||
A Linux memory policy is a tuple consisting of a "mode" and an optional set
|
||||
of nodes. The mode determine the behavior of the policy, while the
|
||||
optional set of nodes can be viewed as the arguments to the behavior.
|
||||
|
||||
Internally, memory policies are implemented by a reference counted
|
||||
structure, struct mempolicy. Details of this structure will be discussed
|
||||
in context, below, as required to explain the behavior.
|
||||
|
||||
Note: in some functions AND in the struct mempolicy itself, the mode
|
||||
is called "policy". However, to avoid confusion with the policy tuple,
|
||||
this document will continue to use the term "mode".
|
||||
|
||||
Linux memory policy supports the following 4 behavioral modes:
|
||||
|
||||
Default Mode--MPOL_DEFAULT: The behavior specified by this mode is
|
||||
context or scope dependent.
|
||||
|
||||
As mentioned in the Policy Scope section above, during normal
|
||||
system operation, the System Default Policy is hard coded to
|
||||
contain the Default mode.
|
||||
|
||||
In this context, default mode means "local" allocation--that is
|
||||
attempt to allocate the page from the node associated with the cpu
|
||||
where the fault occurs. If the "local" node has no memory, or the
|
||||
node's memory can be exhausted [no free pages available], local
|
||||
allocation will "fallback to"--attempt to allocate pages from--
|
||||
"nearby" nodes, in order of increasing "distance".
|
||||
|
||||
Implementation detail -- subject to change: "Fallback" uses
|
||||
a per node list of sibling nodes--called zonelists--built at
|
||||
boot time, or when nodes or memory are added or removed from
|
||||
the system [memory hotplug]. These per node zonelist are
|
||||
constructed with nodes in order of increasing distance based
|
||||
on information provided by the platform firmware.
|
||||
|
||||
When a task/process policy or a shared policy contains the Default
|
||||
mode, this also means "local allocation", as described above.
|
||||
|
||||
In the context of a VMA, Default mode means "fall back to task
|
||||
policy"--which may or may not specify Default mode. Thus, Default
|
||||
mode can not be counted on to mean local allocation when used
|
||||
on a non-shared region of the address space. However, see
|
||||
MPOL_PREFERRED below.
|
||||
|
||||
The Default mode does not use the optional set of nodes.
|
||||
|
||||
MPOL_BIND: This mode specifies that memory must come from the
|
||||
set of nodes specified by the policy.
|
||||
|
||||
The memory policy APIs do not specify an order in which the nodes
|
||||
will be searched. However, unlike "local allocation", the Bind
|
||||
policy does not consider the distance between the nodes. Rather,
|
||||
allocations will fallback to the nodes specified by the policy in
|
||||
order of numeric node id. Like everything in Linux, this is subject
|
||||
to change.
|
||||
|
||||
MPOL_PREFERRED: This mode specifies that the allocation should be
|
||||
attempted from the single node specified in the policy. If that
|
||||
allocation fails, the kernel will search other nodes, exactly as
|
||||
it would for a local allocation that started at the preferred node
|
||||
in increasing distance from the preferred node. "Local" allocation
|
||||
policy can be viewed as a Preferred policy that starts at the node
|
||||
containing the cpu where the allocation takes place.
|
||||
|
||||
Internally, the Preferred policy uses a single node--the
|
||||
preferred_node member of struct mempolicy. A "distinguished
|
||||
value of this preferred_node, currently '-1', is interpreted
|
||||
as "the node containing the cpu where the allocation takes
|
||||
place"--local allocation. This is the way to specify
|
||||
local allocation for a specific range of addresses--i.e. for
|
||||
VMA policies.
|
||||
|
||||
MPOL_INTERLEAVED: This mode specifies that page allocations be
|
||||
interleaved, on a page granularity, across the nodes specified in
|
||||
the policy. This mode also behaves slightly differently, based on
|
||||
the context where it is used:
|
||||
|
||||
For allocation of anonymous pages and shared memory pages,
|
||||
Interleave mode indexes the set of nodes specified by the policy
|
||||
using the page offset of the faulting address into the segment
|
||||
[VMA] containing the address modulo the number of nodes specified
|
||||
by the policy. It then attempts to allocate a page, starting at
|
||||
the selected node, as if the node had been specified by a Preferred
|
||||
policy or had been selected by a local allocation. That is,
|
||||
allocation will follow the per node zonelist.
|
||||
|
||||
For allocation of page cache pages, Interleave mode indexes the set
|
||||
of nodes specified by the policy using a node counter maintained
|
||||
per task. This counter wraps around to the lowest specified node
|
||||
after it reaches the highest specified node. This will tend to
|
||||
spread the pages out over the nodes specified by the policy based
|
||||
on the order in which they are allocated, rather than based on any
|
||||
page offset into an address range or file. During system boot up,
|
||||
the temporary interleaved system default policy works in this
|
||||
mode.
|
||||
|
||||
MEMORY POLICY APIs
|
||||
|
||||
Linux supports 3 system calls for controlling memory policy. These APIS
|
||||
always affect only the calling task, the calling task's address space, or
|
||||
some shared object mapped into the calling task's address space.
|
||||
|
||||
Note: the headers that define these APIs and the parameter data types
|
||||
for user space applications reside in a package that is not part of
|
||||
the Linux kernel. The kernel system call interfaces, with the 'sys_'
|
||||
prefix, are defined in <linux/syscalls.h>; the mode and flag
|
||||
definitions are defined in <linux/mempolicy.h>.
|
||||
|
||||
Set [Task] Memory Policy:
|
||||
|
||||
long set_mempolicy(int mode, const unsigned long *nmask,
|
||||
unsigned long maxnode);
|
||||
|
||||
Set's the calling task's "task/process memory policy" to mode
|
||||
specified by the 'mode' argument and the set of nodes defined
|
||||
by 'nmask'. 'nmask' points to a bit mask of node ids containing
|
||||
at least 'maxnode' ids.
|
||||
|
||||
See the set_mempolicy(2) man page for more details
|
||||
|
||||
|
||||
Get [Task] Memory Policy or Related Information
|
||||
|
||||
long get_mempolicy(int *mode,
|
||||
const unsigned long *nmask, unsigned long maxnode,
|
||||
void *addr, int flags);
|
||||
|
||||
Queries the "task/process memory policy" of the calling task, or
|
||||
the policy or location of a specified virtual address, depending
|
||||
on the 'flags' argument.
|
||||
|
||||
See the get_mempolicy(2) man page for more details
|
||||
|
||||
|
||||
Install VMA/Shared Policy for a Range of Task's Address Space
|
||||
|
||||
long mbind(void *start, unsigned long len, int mode,
|
||||
const unsigned long *nmask, unsigned long maxnode,
|
||||
unsigned flags);
|
||||
|
||||
mbind() installs the policy specified by (mode, nmask, maxnodes) as
|
||||
a VMA policy for the range of the calling task's address space
|
||||
specified by the 'start' and 'len' arguments. Additional actions
|
||||
may be requested via the 'flags' argument.
|
||||
|
||||
See the mbind(2) man page for more details.
|
||||
|
||||
MEMORY POLICY COMMAND LINE INTERFACE
|
||||
|
||||
Although not strictly part of the Linux implementation of memory policy,
|
||||
a command line tool, numactl(8), exists that allows one to:
|
||||
|
||||
+ set the task policy for a specified program via set_mempolicy(2), fork(2) and
|
||||
exec(2)
|
||||
|
||||
+ set the shared policy for a shared memory segment via mbind(2)
|
||||
|
||||
The numactl(8) tool is packages with the run-time version of the library
|
||||
containing the memory policy system call wrappers. Some distributions
|
||||
package the headers and compile-time libraries in a separate development
|
||||
package.
|
||||
|
||||
|
||||
MEMORY POLICIES AND CPUSETS
|
||||
|
||||
Memory policies work within cpusets as described above. For memory policies
|
||||
that require a node or set of nodes, the nodes are restricted to the set of
|
||||
nodes whose memories are allowed by the cpuset constraints. If the
|
||||
intersection of the set of nodes specified for the policy and the set of nodes
|
||||
allowed by the cpuset is the empty set, the policy is considered invalid and
|
||||
cannot be installed.
|
||||
|
||||
The interaction of memory policies and cpusets can be problematic for a
|
||||
couple of reasons:
|
||||
|
||||
1) the memory policy APIs take physical node id's as arguments. However, the
|
||||
memory policy APIs do not provide a way to determine what nodes are valid
|
||||
in the context where the application is running. An application MAY consult
|
||||
the cpuset file system [directly or via an out of tree, and not generally
|
||||
available, libcpuset API] to obtain this information, but then the
|
||||
application must be aware that it is running in a cpuset and use what are
|
||||
intended primarily as administrative APIs.
|
||||
|
||||
However, as long as the policy specifies at least one node that is valid
|
||||
in the controlling cpuset, the policy can be used.
|
||||
|
||||
2) when tasks in two cpusets share access to a memory region, such as shared
|
||||
memory segments created by shmget() of mmap() with the MAP_ANONYMOUS and
|
||||
MAP_SHARED flags, and any of the tasks install shared policy on the region,
|
||||
only nodes whose memories are allowed in both cpusets may be used in the
|
||||
policies. Again, obtaining this information requires "stepping outside"
|
||||
the memory policy APIs, as well as knowing in what cpusets other task might
|
||||
be attaching to the shared region, to use the cpuset information.
|
||||
Furthermore, if the cpusets' allowed memory sets are disjoint, "local"
|
||||
allocation is the only valid policy.
|
||||
@@ -0,0 +1,10 @@
|
||||
00-INDEX
|
||||
- this file.
|
||||
pcwd-watchdog.txt
|
||||
- documentation for Berkshire Products PC Watchdog ISA cards.
|
||||
src/
|
||||
- directory holding watchdog related example programs.
|
||||
watchdog-api.txt
|
||||
- description of the Linux Watchdog driver API.
|
||||
wdt.txt
|
||||
- description of the Watchdog Timer Interfaces for Linux.
|
||||
+10
-4
@@ -167,11 +167,11 @@ S: Maintained
|
||||
P: Eric Van Hensbergen
|
||||
M: ericvh@gmail.com
|
||||
P: Ron Minnich
|
||||
M: rminnich@lanl.gov
|
||||
M: rminnich@sandia.gov
|
||||
P: Latchesar Ionkov
|
||||
M: lucho@ionkov.net
|
||||
L: v9fs-developer@lists.sourceforge.net
|
||||
W: http://v9fs.sf.net
|
||||
W: http://swik.net/v9fs
|
||||
T: git kernel.org:/pub/scm/linux/kernel/ericvh/v9fs.git
|
||||
S: Maintained
|
||||
|
||||
@@ -1009,7 +1009,7 @@ P: Steve French
|
||||
M: sfrench@samba.org
|
||||
L: linux-cifs-client@lists.samba.org
|
||||
L: samba-technical@lists.samba.org
|
||||
W: http://us1.samba.org/samba/Linux_CIFS_client.html
|
||||
W: http://linux-cifs.samba.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git
|
||||
S: Supported
|
||||
|
||||
@@ -2661,6 +2661,12 @@ L: netdev@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
|
||||
S: Maintained
|
||||
|
||||
NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK)
|
||||
P: Paul Moore
|
||||
M: paul.moore@hp.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
NETWORKING [WIRELESS]
|
||||
P: John W. Linville
|
||||
M: linville@tuxdriver.com
|
||||
@@ -3452,7 +3458,7 @@ S: Maintained
|
||||
|
||||
TPM DEVICE DRIVER
|
||||
P: Kylene Hall
|
||||
M: kjhall@us.ibm.com
|
||||
M: tpmdd-devel@lists.sourceforge.net
|
||||
W: http://tpmdd.sourceforge.net
|
||||
P: Marcel Selhorst
|
||||
M: tpm@selhorst.net
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 23
|
||||
EXTRAVERSION =-rc3
|
||||
NAME = Holy Dancing Manatees, Batman!
|
||||
EXTRAVERSION =-rc4
|
||||
NAME = Pink Farting Weasel
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
||||
@@ -23,24 +23,24 @@
|
||||
#include "generic.h"
|
||||
|
||||
#ifdef CONFIG_PCI
|
||||
static int __init micrel_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
|
||||
static int micrel_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
|
||||
{
|
||||
return KS8695_IRQ_EXTERN0;
|
||||
}
|
||||
|
||||
static struct ks8695_pci_cfg micrel_pci = {
|
||||
static struct ks8695_pci_cfg __initdata micrel_pci = {
|
||||
.mode = KS8695_MODE_MINIPCI,
|
||||
.map_irq = micrel_pci_map_irq,
|
||||
};
|
||||
#endif
|
||||
|
||||
|
||||
static void micrel_init(void)
|
||||
static void __init micrel_init(void)
|
||||
{
|
||||
printk(KERN_INFO "Micrel KS8695 Development Board initializing\n");
|
||||
|
||||
#ifdef CONFIG_PCI
|
||||
ks8695_init_pci(&micrel_pci);
|
||||
// ks8695_init_pci(&micrel_pci);
|
||||
#endif
|
||||
|
||||
/* Add devices */
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
config CPU_S3C2442
|
||||
bool
|
||||
depends on ARCH_S3C2420
|
||||
depends on ARCH_S3C2410
|
||||
select S3C2410_CLOCK
|
||||
select S3C2410_GPIO
|
||||
select S3C2410_PM if PM
|
||||
|
||||
@@ -9,6 +9,7 @@
|
||||
*/
|
||||
#include <linux/clk.h>
|
||||
#include <linux/etherdevice.h>
|
||||
#include <linux/i2c-gpio.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/linkage.h>
|
||||
#include <linux/platform_device.h>
|
||||
@@ -123,6 +124,19 @@ static struct platform_device ngw_gpio_leds = {
|
||||
}
|
||||
};
|
||||
|
||||
static struct i2c_gpio_platform_data i2c_gpio_data = {
|
||||
.sda_pin = GPIO_PIN_PA(6),
|
||||
.scl_pin = GPIO_PIN_PA(7),
|
||||
};
|
||||
|
||||
static struct platform_device i2c_gpio_device = {
|
||||
.name = "i2c-gpio",
|
||||
.id = 0,
|
||||
.dev = {
|
||||
.platform_data = &i2c_gpio_data,
|
||||
},
|
||||
};
|
||||
|
||||
static int __init atngw100_init(void)
|
||||
{
|
||||
unsigned i;
|
||||
@@ -147,6 +161,10 @@ static int __init atngw100_init(void)
|
||||
}
|
||||
platform_device_register(&ngw_gpio_leds);
|
||||
|
||||
at32_select_gpio(i2c_gpio_data.sda_pin, 0);
|
||||
at32_select_gpio(i2c_gpio_data.scl_pin, 0);
|
||||
platform_device_register(&i2c_gpio_device);
|
||||
|
||||
return 0;
|
||||
}
|
||||
postcore_initcall(atngw100_init);
|
||||
|
||||
@@ -50,4 +50,30 @@ config BOARD_ATSTK1002_SPI1
|
||||
GPIO lines and accessed through the J1 jumper block. Say "y"
|
||||
here to configure that SPI controller.
|
||||
|
||||
config BOARD_ATSTK1002_J2_LED
|
||||
bool
|
||||
default BOARD_ATSTK1002_J2_LED8 || BOARD_ATSTK1002_J2_RGB
|
||||
|
||||
choice
|
||||
prompt "LEDs connected to J2:"
|
||||
depends on LEDS_GPIO && !BOARD_ATSTK1002_SW4_CUSTOM
|
||||
optional
|
||||
help
|
||||
Select this if you have jumpered the J2 jumper block to the
|
||||
LED0..LED7 amber leds, or to the RGB leds, using a ten-pin
|
||||
IDC cable. A default "heartbeat" trigger is provided, but
|
||||
you can of course override this.
|
||||
|
||||
config BOARD_ATSTK1002_J2_LED8
|
||||
bool "LED0..LED7"
|
||||
help
|
||||
Select this if J2 is jumpered to LED0..LED7 amber leds.
|
||||
|
||||
config BOARD_ATSTK1002_J2_RGB
|
||||
bool "RGB leds"
|
||||
help
|
||||
Select this if J2 is jumpered to the RGB leds.
|
||||
|
||||
endchoice
|
||||
|
||||
endif # stk 1002
|
||||
|
||||
@@ -11,6 +11,7 @@
|
||||
#include <linux/etherdevice.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/leds.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/string.h>
|
||||
#include <linux/types.h>
|
||||
@@ -120,6 +121,65 @@ static void __init set_hw_addr(struct platform_device *pdev)
|
||||
clk_put(pclk);
|
||||
}
|
||||
|
||||
#ifdef CONFIG_BOARD_ATSTK1002_J2_LED
|
||||
|
||||
static struct gpio_led stk_j2_led[] = {
|
||||
#ifdef CONFIG_BOARD_ATSTK1002_J2_LED8
|
||||
#define LEDSTRING "J2 jumpered to LED8"
|
||||
{ .name = "led0:amber", .gpio = GPIO_PIN_PB( 8), },
|
||||
{ .name = "led1:amber", .gpio = GPIO_PIN_PB( 9), },
|
||||
{ .name = "led2:amber", .gpio = GPIO_PIN_PB(10), },
|
||||
{ .name = "led3:amber", .gpio = GPIO_PIN_PB(13), },
|
||||
{ .name = "led4:amber", .gpio = GPIO_PIN_PB(14), },
|
||||
{ .name = "led5:amber", .gpio = GPIO_PIN_PB(15), },
|
||||
{ .name = "led6:amber", .gpio = GPIO_PIN_PB(16), },
|
||||
{ .name = "led7:amber", .gpio = GPIO_PIN_PB(30),
|
||||
.default_trigger = "heartbeat", },
|
||||
#else /* RGB */
|
||||
#define LEDSTRING "J2 jumpered to RGB LEDs"
|
||||
{ .name = "r1:red", .gpio = GPIO_PIN_PB( 8), },
|
||||
{ .name = "g1:green", .gpio = GPIO_PIN_PB(10), },
|
||||
{ .name = "b1:blue", .gpio = GPIO_PIN_PB(14), },
|
||||
|
||||
{ .name = "r2:red", .gpio = GPIO_PIN_PB( 9),
|
||||
.default_trigger = "heartbeat", },
|
||||
{ .name = "g2:green", .gpio = GPIO_PIN_PB(13), },
|
||||
{ .name = "b2:blue", .gpio = GPIO_PIN_PB(15),
|
||||
.default_trigger = "heartbeat", },
|
||||
/* PB16, PB30 unused */
|
||||
#endif
|
||||
};
|
||||
|
||||
static struct gpio_led_platform_data stk_j2_led_data = {
|
||||
.num_leds = ARRAY_SIZE(stk_j2_led),
|
||||
.leds = stk_j2_led,
|
||||
};
|
||||
|
||||
static struct platform_device stk_j2_led_dev = {
|
||||
.name = "leds-gpio",
|
||||
.id = 2, /* gpio block J2 */
|
||||
.dev = {
|
||||
.platform_data = &stk_j2_led_data,
|
||||
},
|
||||
};
|
||||
|
||||
static void setup_j2_leds(void)
|
||||
{
|
||||
unsigned i;
|
||||
|
||||
for (i = 0; i < ARRAY_SIZE(stk_j2_led); i++)
|
||||
at32_select_gpio(stk_j2_led[i].gpio, AT32_GPIOF_OUTPUT);
|
||||
|
||||
printk("STK1002: " LEDSTRING "\n");
|
||||
platform_device_register(&stk_j2_led_dev);
|
||||
}
|
||||
|
||||
#else
|
||||
static void setup_j2_leds(void)
|
||||
{
|
||||
}
|
||||
#endif
|
||||
|
||||
void __init setup_board(void)
|
||||
{
|
||||
#ifdef CONFIG_BOARD_ATSTK1002_SW2_CUSTOM
|
||||
@@ -185,6 +245,8 @@ static int __init atstk1002_init(void)
|
||||
at32_add_device_ssc(0, ATMEL_SSC_TX);
|
||||
#endif
|
||||
|
||||
setup_j2_leds();
|
||||
|
||||
return 0;
|
||||
}
|
||||
postcore_initcall(atstk1002_init);
|
||||
|
||||
@@ -548,6 +548,7 @@ config ETRAX_IDE
|
||||
select BLK_DEV_IDEDISK
|
||||
select BLK_DEV_IDECD
|
||||
select BLK_DEV_IDEDMA
|
||||
select IDE_GENERIC
|
||||
help
|
||||
Enable this to get support for ATA/IDE.
|
||||
You can't use parallel ports or SCSI ports
|
||||
|
||||
@@ -592,6 +592,7 @@ config ETRAX_IDE
|
||||
select BLK_DEV_IDEDISK
|
||||
select BLK_DEV_IDECD
|
||||
select BLK_DEV_IDEDMA
|
||||
select IDE_GENERIC
|
||||
help
|
||||
Enables the ETRAX IDE driver.
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user