On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Peter Dolding wrote:
> >>> What is left unspecified here is 'how' a child 'with its own profile' is
> >>> confined here. Are it is confined to just its own profile, it may that
> >>> the "complicit process" communication may need
arch/alpha/kernel/pci-noop.c:167: warning: 'virt_to_bus' is deprecated
(declared at include2/asm/io.h:117)
arch/alpha/kernel/pci-noop.c: In function 'dma_map_sg':
arch/alpha/kernel/pci-noop.c:183: error: 'struct scatterlist' has no member
named 'page'
arch/alpha/kernel/pci-noop.c:184: error:
> >
> >Any good suggestions here???
> >UTS_MACHINE is set in top-level Makefile and if we specify
> >make ARCH=x86
> >we do not know if i386 or x86_&4 is correct until the configuration
> >has been read.
> >
> >Should we report a "make ARCH=x86" as uname -m == x86??
> >
>
> That would break 5
On Fri, 2007-11-16 at 22:45 -0800, Dane Mutters wrote:
> I thought you might find this helpful. (I brought this issue up with
> the Slackware folks once, and they told me basically this.)
>
> http://wiki.craz1.homelinux.com/index.php/Linux:Security:Forkbomb
>
> I was also told that the ability
I thought you might find this helpful. (I brought this issue up with
the Slackware folks once, and they told me basically this.)
http://wiki.craz1.homelinux.com/index.php/Linux:Security:Forkbomb
I was also told that the ability to spawn such rampant forks/processes
is controlled by default in
Sorry! I forgot to put in a prologue for this patch.
Here it is.
This patch changes the searching for a run queue by a waking RT task
to try to pick another runqueue if the currently running task
is an RT task.
The reason is that RT tasks behave different than normal
tasks. Preempting a
This patch adds the algorithm to pull tasks from RT overloaded runqueues.
When a pull RT is initiated, all overloaded runqueues are examined for
a RT task that is higher in prio than the highest prio task queued on the
target runqueue. If another runqueue holds a RT task that is of higher
prio
Gregory Haskins RT balancing broke sched domains.
This is a fix to allow it to still work.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
include/linux/sched.h |3 ++-
kernel/sched.c | 17 ++---
kernel/sched_fair.c | 19 ++-
This patch adds accounting to each runqueue to keep track of the
highest prio task queued on the run queue. We only care about
RT tasks, so if the run queue does not contain any active RT tasks
its priority will be considered MAX_RT_PRIO.
This information will be used for later patches.
From: Gregory Haskins <[EMAIL PROTECTED]>
Isolate the search logic into a function so that it can be used later
in places other than find_locked_lowest_rq().
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched_rt.c | 62
From: Gregory Haskins <[EMAIL PROTECTED]>
In the original patch series that Steven Rostedt and I worked on together,
we both took different approaches to low-priority wakeup path. I utilized
"pre-routing" (push the task away to a less important RQ before activating)
approach, while Steve
From: Gregory Haskins <[EMAIL PROTECTED]>
"this_rq" is normally used to denote the RQ on the current cpu
(i.e. "cpu_rq(this_cpu)"). So clean up the usage of this_rq to be
more consistent with the rest of the code.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
Signed-off-by: Steven Rostedt
This patch adds an algorithm to push extra RT tasks off a run queue to
other CPU runqueues.
When more than one RT task is added to a run queue, this algorithm takes
an assertive approach to push the RT tasks that are not running onto other
run queues that have lower priority. The way this works
This patch adds accounting to keep track of the number of RT tasks running
on a runqueue. This information will be used in later patches.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched.c|1 +
kernel/sched_rt.c | 17 +
2 files changed, 18
From: Gregory Haskins <[EMAIL PROTECTED]>
We have logic to detect whether the system has migratable tasks, but we are
not using it when deciding whether to push tasks away. So we add support
for considering this new information.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
Signed-off-by:
Since we now take an active approach to load balancing, we don't need to
balance RT tasks via CFS. In fact, this code was found to pull RT tasks
away from CPUS that the active movement performed, resulting in
large latencies.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
This patch adds pushing of overloaded RT tasks from a runqueue that is
having tasks (most likely RT tasks) added to the run queue.
TODO: We don't cover the case of waking of new RT tasks (yet).
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched.c|3 +++
kernel/sched_rt.c
From: Gregory Haskins <[EMAIL PROTECTED]>
The current wake-up code path tries to determine if it can optimize the
wake-up to "this_cpu" by computing load calculations. The problem is that
these calculations are only relevant to CFS tasks where load is king. For RT
tasks, priority is king. So
This patch adds an RT overload accounting system. When a runqueue has
more than one RT task queued, it is marked as overloaded. That is that it
is a candidate to have RT tasks pulled from it.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
kernel/sched_rt.c | 36
From: Gregory Haskins <[EMAIL PROTECTED]>
It doesn't hurt if we allow the current CPU to be included in the
search. We will just simply skip it later if the current CPU turns out
to be the lowest.
We will use this later in the series
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
From: Gregory Haskins <[EMAIL PROTECTED]>
The current code base assumes a relatively flat CPU/core topology and will
route RT tasks to any CPU fairly equally. In the real world, there are
various toplogies and affinities that govern where a task is best suited to
run with the smallest amount of
Index: linux-compile.git/kernel/sched_rt.c
===
--- linux-compile.git.orig/kernel/sched_rt.c2007-11-17 00:18:27.0
-0500
+++ linux-compile.git/kernel/sched_rt.c 2007-11-17 00:20:31.0 -0500
@@ -52,11 +52,23 @@ static
From: Gregory Haskins <[EMAIL PROTECTED]>
Some RT tasks (particularly kthreads) are bound to one specific CPU.
It is fairly common for two or more bound tasks to get queued up at the
same time. Consider, for instance, softirq_timer and softirq_sched. A
timer goes off in an ISR which schedules
[
Changes since V2:
Updated to git tree 8c0863403f109a43d7000b4646da4818220d501f
This version also contains patches from Gregory Haskins.
Actually brought back the global RT overload bitmask.
The reason is that it should be seldom written to. The RT
overload bitmask is
wing patches provide an alternative implementation of the
sys_indirect system call which has been discussed a few times.
This no system call allows us to extend existing system call
interfaces with adding more system calls.
Davide's previous implementation is IMO far more complex than
warranted.
Hmmm.. Lots of small fixes, some cleanups, and a few things like the cris
updates that aren't really either, but which won't affect any normal user,
and will hopefully make it easier to sync up in the future.
Network driver fixes, some IDE and infiniband updates, some late cpufreq
updates,
This part adds support for sys_indirect for UML.
indirect.h |6 ++
1 file changed, 6 insertions(+)
--- /dev/null
+++ include/asm-um/indirect.h
@@ -0,0 +1,6 @@
+#ifndef __UM_INDIRECT_H
+#define __UM_INDIRECT_H
+
+#include "asm/arch/indirect.h"
+
+#endif
-
To unsubscribe from this list:
This part adds support for sys_indirect on x86 and x86-64.
arch/x86/ia32/ia32entry.S |2 ++
arch/x86/ia32/sys_ia32.c | 31 +++
arch/x86/kernel/syscall_table_32.S |1 +
include/asm-x86/indirect.h |5 +
This is a first user of sys_indirect. Several of the socket-related system
calls which produce a file handle now can be passed an additional parameter
to set the FD_CLOEXEC flag.
arch/x86/ia32/Makefile|1 +
arch/x86/ia32/sys_ia32.c |4
include/asm-x86/ia32_unistd.h |
This is the actual architecture-independent part of the system call
implementation.
include/linux/indirect.h |6 ++
include/linux/sched.h|4
include/linux/syscalls.h |4
kernel/Makefile |2 +-
kernel/indirect.c| 36
Hello.
Trond Myklebust wrote:
> I'm confused. How do you tell the difference between a 'userland'
> request and a 'kernel' request, and why is the latter safe from a
> security perspective?
For example, if userland process wants to create a directory,
it will call mkdir(2).
In the kernel,
On Fri, 16 Nov 2007 23:25:27 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > does somebody know if there is a website or a project for giving
> > comfortable and deeper insight into what`s specific to distro`s
> > kernels and what`s their difference to vanilla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
This warning is just saying that you might want to reconsider
recompiling your dhclient with a newer libcap - which has native support
for 64-bit capabilities. This is supposed to be informative, and not be
associated with any particular error.
On Sat, 2007-11-17 at 13:04 +0900, Tetsuo Handa wrote:
> Hello.
>
> Trond Myklebust wrote:
> > The problem is that you have thrown away the main tool for documenting
> > the requirement, and for enforcing correctness (i.e. function argument
> > checking by the compiler).
> I'm sorry. I wanted to
Use hlist_unhashed() instead of opencoded equivalent.
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
fs/dcache.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: 2.6-mm/fs/dcache.c
===
---
Hi,
I've build by 'accident' and stable kernel inside a git repo and noticed an
strange bug.
setlocalversion will append a git revision to the kernel even is not an git one.
to reproduce create some dir and cd in there:
git init
git config user.email "[EMAIL PROTECTED]"
git config user.name
Hello.
Trond Myklebust wrote:
> The problem is that you have thrown away the main tool for documenting
> the requirement, and for enforcing correctness (i.e. function argument
> checking by the compiler).
I'm sorry. I wanted to know whether the below approach is possible.
> The old functions are
Hello.
Thank you for your feedback.
Paul Moore wrote:
> With this patch the 'cpu_flags' variable will be used in two different
> if-blocks in this function and declared locally within each block. Please
> move the 'cpu_flags' declaration to the top of the function so it only needs
> to be
On Fri, Nov 16, 2007 at 04:25:38PM -0800, Abhishek Rai wrote:
> Ideally, this is how things should be done, but I feel in practice, it
> will make little difference. To summarize, the difference between
> my approach and above approach is that when out of free blocks in a
> block group while
applied.
thanks,
-len
On Friday 09 November 2007 01:02, Adrian Bunk wrote:
> This patch fixes the following section mismatches with CONFIG_HOTPLUG=n:
>
> <-- snip -->
>
> ...
> WARNING: vmlinux.o(.data+0x23640): Section mismatch: reference to
> .init.text.20:can_skip_ioresource_align
applied.
thanks,
-len
On Friday 09 November 2007 01:03, Adrian Bunk wrote:
> acpi_pci_link_exit() is both unused and empty.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> 16d6853a1facb9bcb7a4bc19daad6d3b852cace3
> diff --git a/arch/x86/kernel/acpi/sleep_64.c
On Sat, Nov 17, 2007 at 02:48:45AM +0100, Patrick DEMICHEL wrote:
> Thanks Greg,
>
>but for external people it seems there is lot of people with opposite
> opinions, for sure some are valid and they can be focused on different
> things. But for example this critical topic seems quite not
On Sat, Nov 17, 2007 at 02:13:13AM +0100, Patrick DEMICHEL wrote:
> Yet another noisy linux HPC user
>
> I hope to convince you, lkml developers, to pay more attention to our HPC
> performance problems.
We do pay attention, and want to help out, we just need either bug
reports of problems that
I have a USB libertas 1286:2001 with bcdDevice 30.06 (from lsusb -v).
I tried downloading the firmware from marvell:
https://www.marvell.com/drivers/driverDisplay.do?dId=160=38
renaming and to usb8388.bin and putting it in firmware dir. Is this
the right firmware??
Upon load this is what I get:
On Fri, 16 Nov 2007 18:11:00 -0600, Timur Tabi wrote:
> A private data pointer in struct device_attribute allows the 'show' and
> 'store'
> functions to access instance data. This handy in situations where the
> driver_data and platform_data pointers of 'struct device' are already used
> for
On Fri, Nov 16, 2007 at 04:29:05PM -0800, David Miller wrote:
> From: dean gaudet <[EMAIL PROTECTED]>
> Date: Fri, 16 Nov 2007 09:51:08 -0800 (PST)
>
> > On Fri, 16 Nov 2007, Andi Kleen wrote:
> >
> > > I didn't see a clear list.
> >
> > - cross platform extensible API for configuring perf
On Sat, Nov 17, 2007 at 02:15:11AM +0300, Michael Tokarev wrote:
> Greg Kroah-Hartman wrote:
> > We (the -stable team) are announcing the release of the 2.6.23.3 kernel.
> > It contains a number of bugfixes for a number of architecture specific
> > issues.
> [.4, .5, .6 and .7 follows after .2 and
On Fri, Nov 16, 2007 at 06:11:00PM -0600, Timur Tabi wrote:
> A private data pointer in struct device_attribute allows the 'show' and
> 'store'
> functions to access instance data. This handy in situations where the
> driver_data and platform_data pointers of 'struct device' are already used
>
Peter Dolding wrote:
>>> What is left unspecified here is 'how' a child 'with its own profile' is
>>> confined here. Are it is confined to just its own profile, it may that
>>> the "complicit process" communication may need to be wider specified to
>>> include this.
>>>
> Sorry have to
On Sat, Nov 17, 2007 at 12:26:41AM +0100, Dmitry Adamushko wrote:
> Let's say we change a pattern for the niced task: e.g. run for 100 ms.
> and then sleep for 300 ms. (that's ~25% of cpu load) in the loop. Any
> behavioral changes?
For consistency, I tested this using /dev/rtc. I set the rtc
It'd be helpful to see others (especially kprobes maintainers) chime in
on this. In particular, if doing kmalloc/kfree of GFP_ATOMIC data at
kretprobe-hit time is OK, as in Abhishek's approach, then we could also
use GFP_ATOMIC (or at least GFP_NOWAIT) allocations to make up the
difference when
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Fri, 16 Nov 2007 14:16:11 -0800
> Can you please use your *poof* trick one more time to set up
> [EMAIL PROTECTED]
Done, enjoy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Hi Dave,
* David Miller <[EMAIL PROTECTED]> [071114 02:09]:
>
> In fact, *poof*, there it is, [EMAIL PROTECTED] is there and
> available for anyone who wants to use it.
Can you please use your *poof* trick one more time to set up
[EMAIL PROTECTED]
We've (as in linux-omap community) would
From: dean gaudet <[EMAIL PROTECTED]>
Date: Fri, 16 Nov 2007 09:51:08 -0800 (PST)
> On Fri, 16 Nov 2007, Andi Kleen wrote:
>
> > I didn't see a clear list.
>
> - cross platform extensible API for configuring perf counters
> - support for multiplexed counters
> - support for virtualized 64-bit
Thanks for the great feedback.
On Nov 16, 2007 1:11 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 15, 2007 at 11:02:19PM -0800, Andrew Morton wrote:
> > What happens when it fills up but we still have room for more data blocks
> > in that blockgroup?
>
> It does fall back, but it does
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Fri, 16 Nov 2007 16:15:56 +0100
> Philip Mucci <[EMAIL PROTECTED]> writes:
> > - A feature which was dropped earlier by Stefane (only to satiate
> > LKML), we consider
> > very important. Allowing one tomapping of the kernels view of the
> > PMD's,
Well, the previous patch wasn't correct. This one is valid.
--
This patch adds power management support in mac80211.
This allows us to enable power management through the "iwconfig power
" command.
The code is based on "mac80211-10.0.0" but it is a little bit modified.
Signed-off-by: Miguel
A private data pointer in struct device_attribute allows the 'show' and 'store'
functions to access instance data. This handy in situations where the
driver_data and platform_data pointers of 'struct device' are already used
for other purposes.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
On Fri, 16 Nov 2007, Luck, Tony wrote:
> +# Maximum of 128 MB cpu_alloc space per cpu
> +config CPU_AREA_ORDER
> + int
> + default "13"
>
> Comment only matches code when page size is 16K ... and we are (slowly)
> moving to 64k as the default (which with order 13 allocation would mean
>
On Fri, 16 Nov 2007 22:53:08 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Time has come to change NR_OPEN value, some production servers hit the
> not so 'ridiculously high value' of 1024*1024 file descriptors per process.
Why fiddle with the kernel defaults when every distribution can manage
This message contains a list of some regressions from 2.6.23 which have been
reported since 2.6.24-rc1 was released and for which there are no fixes in the
mainline that I know of. If any of them have been fixed already, please let me
know.
If you know of any other unresolved regressions from
> 3. Run this command:
>
> :(){ :|:& };:
>
> 4. Ubuntu starts to work furiously, after less than a second terminal
> gets flooded with "low resources" message,
Set your system with suitable process and user resource limits. Also I'd
suggest setting memory overcommit to strict.
Our
On Sat, 17 Nov 2007, Remy Bohmer wrote:
> Hello Steven,
>
> Thanks for your reply
>
> > The above sounds more like you need a completion.
> Funny, I first started with using completion structures, but that did
> not work either. I get similar OOPses on all these kind of locking
> mechanisms,
On Fri, 2007-11-16 at 13:57 -0600, Matt Mackall wrote:
> What is the proper encoding for a patch that contains hunks in
> multiple character sets?
That should only happen when we're fixing legacy crap to become UTF-8 --
and in that case, it's probably best to just handle it with a git-pull
rather
+# Maximum of 128 MB cpu_alloc space per cpu
+config CPU_AREA_ORDER
+ int
+ default "13"
Comment only matches code when page size is 16K ... and we are (slowly)
moving to 64k as the default (which with order 13 allocation would mean
512M)
-Tony
-
To unsubscribe from this list: send
H. Peter Anvin wrote:
Should we report a "make ARCH=x86" as uname -m == x86??
That would break 5 years of a stable ABI. I don't think that is even
remotely feasible.
Make that 5 years for x86-64, 16 years for i386...
-hpa
-
To unsubscribe from this list: send the line
On 16/11/2007, Micah Dowty <[EMAIL PROTECTED]> wrote:
> [ ... ]
> > or just remove bit #3 (which is responsible for 8 == 1000) here:
> >
> > cat /proc/sys/kernel/sched_features
> >
> > (this one is enabled by default in 2.6.23.1)
>
> Aha. Turning off bit 3 appears to instantly fix my problem while
On Sat, 2007-11-17 00:20:20 +0100, Xavier Bestel <[EMAIL PROTECTED]> wrote:
>
> I have replaced my machine with another one which gives many ECC errors.
> At first sight they may be pessimistic because memtest (with ECC off)
> doesn't find anything (I'm letting run it overnight, I'll see tomorrow
Hi,
I have replaced my machine with another one which gives many ECC errors.
At first sight they may be pessimistic because memtest (with ECC off)
doesn't find anything (I'm letting run it overnight, I'll see tomorrow
morning if it really didn't find anything).
I'd like to let it run without
Greg Kroah-Hartman wrote:
> We (the -stable team) are announcing the release of the 2.6.23.3 kernel.
> It contains a number of bugfixes for a number of architecture specific
> issues.
[.4, .5, .6 and .7 follows after .2 and .3]
I've seen the bunch of patches posted for review - split to several
On Thu, 15 Nov 2007 22:30:59 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Linus:
> On the per-architecture side, I do think it would be better to *not* have
> internal architecture knowledge in a generic file, and as such a line like
>
> depends on X86_32 || IA64 || PPC || S390
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_irq.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
Index: linux-2.6/drivers/infiniband/hw/ehca/ehca_irq.c
On Sat, 2007-11-17 at 00:23 +0530, Abhishek Sagar wrote:
> On Nov 16, 2007 5:37 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-11-15 at 20:30 +0530, Abhishek Sagar wrote:
> > > On Nov 15, 2007 4:21 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > > > 2. Simplify the task of
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
crypto/async_tx/async_tx.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6/crypto/async_tx/async_tx.c
===
---
The iucv is the only user of the various functions that are used to bring
parts of cpus up and down. Its the only allocpercpu user that will do
I/O on per cpu objects (which is difficult to do with virtually mapped memory).
And its the only use of allocpercpu where a GFP_DMA allocation is done.
There is no user of allocpercpu left after all the earlier patches were
applied. Remove the code that realizes allocpercpu.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/percpu.h | 80 --
mm/Makefile|1
mm/allocpercpu.c
Use the cpu alloc functions for the mib handling functions in the net
layer. The API for snmp_mib_free() is changed to add a size parameter
since cpu_fre requires that.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/net/ip.h|2 +-
include/net/snmp.h | 14
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
drivers/net/chelsio/sge.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
Index: linux-2.6/drivers/net/chelsio/sge.c
===
---
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
net/core/sock.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/net/core/sock.c
===
--- linux-2.6.orig/net/core/sock.c 2007-11-15
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
block/blktrace.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/block/blktrace.c
===
--- linux-2.6.orig/block/blktrace.c 2007-11-15
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
drivers/net/veth.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/drivers/net/veth.c
===
--- linux-2.6.orig/drivers/net/veth.c
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
drivers/net/loopback.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/drivers/net/loopback.c
===
--- linux-2.6.orig/drivers/net/loopback.c
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
drivers/dma/dmaengine.c | 27 ++-
include/linux/dmaengine.h |4 ++--
2 files changed, 16 insertions(+), 15 deletions(-)
Index: linux-2.6/drivers/dma/dmaengine.c
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
net/ipv4/ipcomp.c | 26 +-
net/ipv6/ipcomp6.c | 26 +-
2 files changed, 26 insertions(+), 26 deletions(-)
Index: linux-2.6/net/ipv4/ipcomp.c
Also remove the useless zeroing after allocation. Allocpercpu already
zeroed the objects.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/xfs/xfs_mount.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
Index: linux-2.6/fs/xfs/xfs_mount.c
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/net/ipv4/tcp.c
===
--- linux-2.6.orig/net/ipv4/tcp.c 2007-11-15
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/net/neighbour.h |2 +-
net/core/neighbour.c| 11 ++-
2 files changed, 7 insertions(+), 6 deletions(-)
Index: linux-2.6/include/net/neighbour.h
===
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/nfs/iostat.h |8
fs/nfs/super.c |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/fs/nfs/iostat.h
===
---
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/genhd.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/include/linux/genhd.h
===
--- linux-2.6.orig/include/linux/genhd.h
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
kernel/rcutorture.c |4 ++--
kernel/srcu.c | 11 ++-
2 files changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6/kernel/rcutorture.c
===
---
Enable a simple virtual configuration with 32MB available per cpu so that
we do not use a static area on sparc64.
[Not tested. I have no sparc64]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
arch/sparc64/Kconfig | 15 +++
include/asm-sparc64/pgtable.h |1
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
arch/x86/kernel/acpi/cstate.c |9 +
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |7 ---
drivers/acpi/processor_perflib.c |4 ++--
3 files changed, 11 insertions(+), 9 deletions(-)
Index:
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
kernel/workqueue.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
Index: linux-2.6/kernel/workqueue.c
===
---
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
lib/percpu_counter.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6/lib/percpu_counter.c
===
--- linux-2.6.orig/lib/percpu_counter.c
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
arch/ia64/kernel/crash.c |2 +-
drivers/base/cpu.c |2 +-
kernel/kexec.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/arch/ia64/kernel/crash.c
Typical use of per cpu memory for a small system of 8G 8p 4node is less than
64k per cpu memory. This is increasing rapidly for larger systems where we can
get up to 512k or 1M of memory used for cpu storage.
The maximum size allowed of the cpu area is 128MB of memory.
The cpu area is placed in
64 bit:
Set up a cpu area that allows the use of up 16MB for each processor.
Cpu memory use can grow a bit. F.e. if we assume that a pageset
occupies 64 bytes of memory and we have 3 zones in each of 1024 nodes
then we need 3 * 1k * 16k = 50 million pagesets or 3096 pagesets per
processor. This
Virtually map the cpu areas. This allows bigger maximum sizes and to only
populate the virtual mappings on demand.
In order to use the virtual mapping capability the arch must setup some
configuration variables in arch/xxx/Kconfig:
CONFIG_CPU_AREA_VIRTUAL to y
CONFIG_CPU_AREA_ORDER
to
Use the new cpu_alloc functionality to avoid per cpu arrays in struct zone.
This drastically reduces the size of struct zone for systems with a large
amounts of processors and allows placement of critical variables of struct
zone in one cacheline even on very large systems.
Another effect is that
Using cpu alloc removes the needs for the per cpu arrays in the kmem_cache
struct.
These could get quite big if we have to support system of up to thousands of
cpus.
The use of alloc_percpu means that:
1. The size of kmem_cache for SMP configuration shrinks since we will only
need 1 pointer
1 - 100 of 842 matches
Mail list logo
