From: Cliff Wickman
The crash kernel is not able to find its root device if that device is not
on PCI 0.
This is because it is booted with the command line option memmap=exactmap
which currently clears the e820 table. So ACPI processing does not
find reserved i/o spaces.
This works for a
On Thu, Apr 04, 2013 at 08:17:08AM +0800, Simon Jeons wrote:
> On 03/07/2013 05:50 AM, Cliff Wickman wrote:
>> From: Cliff Wickman
>>
>> Allocating a large number of 1GB hugetlbfs pages at boot takes a
>> very long time.
>>
>> Large system sites would at tim
, but a very big loss to us, both
professionally and personally.
-Cliff
Reported-by: Jan Beulich
Signed-off-by: Alex Shi
Acked-by: Cliff Wickman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
---
arch/x86/include/asm/uv/uv.h |2 +-
arch/x86/platform/uv/tlb_uv.c | 1
Update cpuset documentation to match the October 2007
"Fix cpusets update_cpumask" changes that now apply
changes to a cpusets 'cpus' allowed mask immediately
to the cpus_allowed of the tasks in that cpuset.
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked
to cpuset_attach() in various comments.
Removed comment about not needing memory migration, as it
seems the migration is done anyway, via the cpuset_attach()
callback from cgroup_attach_task().
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked-by: Cliff Wickman <[EMAIL PROTECTED]>
---
k
As of the October 2007 kernel/cpuset.c patch "Memoryless nodes:
Use N_HIGH_MEMORY for cpusets", cpuset nodes are relative to
the nodes with (HIGH) memory, not relative to all nodes in
node_online_map.
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked-by: Cliff Wickman &
]>
Acked-by: Cliff Wickman <[EMAIL PROTECTED]>
---
kernel/cpuset.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
Index: linux-2.6/kernel/cpuset.c
===
--- linux-2.6.orig/kernel/cpuset.c
+++
From: Cliff Wickman
(this was sent as an ack on 9/13, but with incorrect title and sign-off)
Ack.
But with the adjustment below. The 'end' argument was not declared long.
I tested the patch on a UV.
It has the effect of either clearing 1 or all TLBs in a cpu.
I added some debuggi
On Thu, Dec 20, 2012 at 12:22:14PM +0900, HATAYAMA Daisuke wrote:
> From: Cliff Wickman
> Subject: Re: [PATCH] makedumpfile: request the kernel do page scans
> Date: Mon, 10 Dec 2012 09:36:14 -0600
> > On Mon, Dec 10, 2012 at 09:59:29AM +0900, HATAYAMA Daisuke wrote:
> >
lfcorehdr_size);
> > + if (rc)
> > + return rc;
> > + /*
> > +* If elfcorehdr= has been passed in cmdline or created in 2nd kernel,
> > +* then capture the dump.
> > +*/
> > if (!(is_vmcore_usable()))
> > return rc;
> > rc = parse_crash_elf_header
bal reference unit sgi-gru/grufile.c
- sgi special memorychar/mspec.c
- and probably several out-of-tree modules
I'm copying everyone who has changed this file recently, in case
there is some reason that I am not aware of to provide
/proc//smaps|clear_refs|maps|numa_maps for these VM_
age(pfn)
>
> And I guess this race can also happen on reading pagemap or numa_maps because
> walk_page_range() is called in those code paths. Are you sure the race doesn't
> happen on these paths? If not, please add a few more flag checks for them.
Okay. I'll check and submi
for these VM_PFNMAP areas.
Signed-off-by: Cliff Wickman
---
mm/pagewalk.c | 60 +-
1 file changed, 31 insertions(+), 29 deletions(-)
Index: linux/mm/pagewalk.c
===
--- linux.ori
On Wed, May 01, 2013 at 08:47:02AM -0700, David Rientjes wrote:
> On Wed, 1 May 2013, Cliff Wickman wrote:
>
> > Index: linux/mm/pagewalk.c
> > ===
> > --- linux.orig/mm/pagewalk.c
> > +++ linux/mm/pa
r_refs|maps|numa_maps for these VM_PFNMAP areas.
Signed-off-by: Cliff Wickman
---
mm/pagewalk.c | 62 ++
1 file changed, 33 insertions(+), 29 deletions(-)
Index
On Thu, May 02, 2013 at 12:44:04PM -0400, Naoya Horiguchi wrote:
> On Thu, May 02, 2013 at 07:10:48AM -0500, Cliff Wickman wrote:
> >
> > /proc//smaps and similar walks through a user page table should not
> > be looking at VM_PFNMAP areas.
> >
> > This is v2:
hem.
(versus Jingbai Ma's results where mmap almost doubled the speed of reads)
I have put counters in to verify, and we are doing several million
seek/read's vs. a few thousand mmap's. Yet the performance is similar
(54sec vs. 37sec, above). I can't rationalize that
roc/vmcore about 80x faster than the
read interface.
That is, doing mmap's and copying data (in pieces the size of page
structures) transfers all of /proc/vmcore about 80 times faster than
reading it.
This greatly speeds up the capture of a kdump, as the scan of page
structures takes the bulk
cently, in case
of some reason to provide /proc//smaps for these areas that I am not
aware of.
Signed-off-by: Cliff Wickman
---
fs/proc/task_mmu.c |3 +++
1 file changed, 3 insertions(+)
Index: linux/fs/proc/task_mmu.c
===
--- lin
> On Thur, 23 May 2013 Andrew Morton wrote:
> > On Wed, 15 May 2013 07:46:36 -0500 Cliff Wickman wrote:
> > Certain tests in walk_page_range() (specifically split_huge_page_pmd())
> > assume that all the mapped PFN's are backed with page structures. And this
>
From: Cliff Wickman
Allocating a large number of 1GB hugetlbfs pages at boot takes a
very long time.
Large system sites would at times like to allocate a very large amount of
memory as 1GB pages. They would put this on the kernel boot line:
default_hugepagesz=1G hugepagesz=1G hugepages
On Sun, Mar 10, 2013 at 01:55:10PM +0800, Hillf Danton wrote:
> On Thu, Mar 7, 2013 at 5:50 AM, Cliff Wickman wrote:
> > From: Cliff Wickman
> >
> > Allocating a large number of 1GB hugetlbfs pages at boot takes a
> > very long time.
> >
> > Large system
Hi Paul,
> Query for Cliff:
> 1) Can we narrow the scope of callback_mutex in scan_for_empty_cpusets()?
> 2) Can we avoid rewriting the cpus, mems of cpusets except when it is
>likely that we'll be changing them?
> 3) Should not remove_tasks_in_empty_cpuset() also check for empty mems?
> -pj
As of the October 2007 kernel/cpuset.c patch "Memoryless nodes:
Use N_HIGH_MEMORY for cpusets", cpuset nodes are relative to
the nodes with (HIGH) memory, not relative to all nodes in
node_online_map.
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked-by: Cliff Wickman &
]>
Acked-by: Cliff Wickman <[EMAIL PROTECTED]>
---
kernel/cpuset.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
Index: linux-2.6/kernel/cpuset.c
===
--- linux-2.6.orig/kernel/cpuset.c
+++
Update cpuset documentation to match the October 2007
"Fix cpusets update_cpumask" changes that now apply
changes to a cpusets 'cpus' allowed mask immediately
to the cpus_allowed of the tasks in that cpuset.
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked
]>
Acked-by: Cliff Wickman <[EMAIL PROTECTED]>
---
kernel/cpuset.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
Index: linux-2.6/kernel/cpuset.c
===
--- linux-2.6.orig/kernel/cpuset.c
+++
to cpuset_attach() in various comments.
Removed comment about not needing memory migration, as it
seems the migration is done anyway, via the cpuset_attach()
callback from cgroup_attach_task().
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked-by: Cliff Wickman <[EMAIL PROTECTED]>
---
to cpuset_attach() in various comments.
Removed comment about not needing memory migration, as it
seems the migration is done anyway, via the cpuset_attach()
callback from cgroup_attach_task().
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked-by: Cliff Wickman <[EMAIL PROTECTED]>
---
mentation. I would propose this note
in cpu-hotplug.txt.
Diffed against 2.6.23-rc3
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
---
Documentation/cpu-hotplug.txt |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linus.070821/Docu
by itself, it finds both sda and sdb.
But when it is loaded by kexec and booted on a panic it only finds sda.
Any ideas from those familiar with the ATA driver?
-Cliff Wickman
SGI
I put some printk's into it and get th
In the 2.6.21 kernel there are still 3 hotplug issues that are cpuset-
related, and that I find to still be problems. And for which I offer
patches.
These have been submitted before, and subsequently cleaned up per
comments received. I'm resubmitting all 3 for consideration and further
commen
a sched_group that
points to itself. This is needed because cpu's are going through
load balancing before all sched_domains have been reconstructed (see
the example above).
Thus the patch to sched.c prevents the hangs that would otherwise occur
until the sched_domain's are made correct.
cpuset locks.
(I've been working with Paul Jackson on this patch, and there is still a
little functional subtlety to work out. Can be tweaked later.)
Diffed against 2.6.21
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
---
kernel/cpus
cpuset, but is still attached to
that cpuset (by pointer and reference count). The cpuset will not be
released. This patch does not change that.]
Diffed against 2.6.21
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
kernel/sched.c | 31 ++
On Thu, May 24, 2007 at 01:29:02AM +0400, Oleg Nesterov wrote:
> Cliff Wickman wrote:
> >
> > In order to do this, move_task_off_dead_cpu() must make a call to
> > cpuset_cpus_allowed(), which may block.
> >
> > move_task_off_dead_cpu() has been within a cri
From: Cliff Wickman <[EMAIL PROTECTED]>
(this is a second submission -- the first was from a work area back
porting to an older release)
When a cpu is disabled, move_task_off_dead_cpu() is called for tasks
that have been running on that cpu.
Currently, such a task is migrated:
1) to a
From: Cliff Wickman <[EMAIL PROTECTED]>
This patch reconciles cpusets and sched_domains that get out of sync
due to disabling and re-enabling of cpu's.
Dinakar Guniguntala (IBM) is working on his own version of fixing this.
But as of this date that fix doesn't seem to be re
From: Cliff Wickman <[EMAIL PROTECTED]>
This patch corrects a situation that occurs when one disables all the cpus
in a cpuset.
At that point, any tasks in that cpuset are incorrectly moved (as I recall,
they were move to a sibling cpuset).
Such tasks should be move the parent of their c
not to do memory
allocation while holding the cpusets callback_mutex. And it makes use of the
"cpuset_release_agent" to do the cpuset removals.
It might be simpler to use a separate thread or workqueue. But such code
has not yet been written.
Diffed against 2.6.20-rc6
Signed-off-by: Cli
Hello Andrew,
On Thu, Mar 22, 2007 at 02:21:52PM -0700, Andrew Morton wrote:
> On Tue, 20 Mar 2007 13:14:35 -0600
> [EMAIL PROTECTED] (Cliff Wickman) wrote:
>
> > This patch reconciles cpusets and sched_domains that get out of sync
> > due to disabling and re-enabling of cp
From: Cliff Wickman <[EMAIL PROTECTED]>
When a cpu is disabled, move_task_off_dead_cpu() is called for tasks
that have been running on that cpu.
Currently, such a task is migrated:
1) to any cpu on the same node as the disabled cpu, which is both online
and among that task's c
sysconf returned values should be affected by affinity.
I'm looking at an ia64 system, and when a cpu is hot-unplugged it is removed
from /proc/cpuinfo. Wouldn't /sys/devices/system/cpu/ be a better
source for 2) ?
--
Cliff Wickman
Silicon Graphics, Inc.
[EMAIL PROTECTED]
(651) 683-3824
-
ata structure.
The vma's are protected by mm->mmap_sem, so the reference count was changed
from an atomic_t to an int.
Diffed against 2.6.13-rc5
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
Acked-by: Jes Sorensen <[EMAIL PROT
vma. This is
enabled by storing the vma group's vm_start in the vma_data structure.
The shared vma_data's are not protected by mm->mmap_sem in the fork() case
so the reference count is left as atomic_t.
Diffed against 2.6.13-rc5
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
A
addresses
using the portion of the array that represents the current vma. This is
enabled by storing the vma group's vm_start in the vma_data structure.
The shared vma_data's are not protected by mm->mmap_sem in the fork() case
so the reference count is left as atomic_t.
Diffed again
e count is left as atomic_t.
Each section of the vma_data structure may be shared by multiple tasks
(forked from the same parent). So single thread mspec_close() during the
zeroing of a vma's section.
Diffed against 2.6.23-rc5
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]&
are shared or not shared, so release/clear
pages only when the refcount (of vma's) goes to zero.
Diffed against 2.6.23-rc5
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
Acked-by: Jes Sorensen <[EMAIL PROTECTED]>
---
drivers/char/mspec.c | 64 +
iple tasks, with
no way of knowing which areas are shared or not shared, so release/clear
pages only when the refcount (of vma's) goes to zero.
Diffed against 2.6.23-rc7
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
---
drivers/char/mspec.c | 26 --
1 file
2] do CPU_DEAD migrating under read_lock(tasklist) instead of
write_lock_irq(tasklist)
[PATCH 2/2] migration_call(CPU_DEAD): use spin_lock_irq() instead of
task_rq_lock()
Diffed against 2.6.23-rc3
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
---
include/linux/cpuset.h |5
EAD migrating under read_lock(tasklist) instead of
write_lock_irq(tasklist)
[PATCH 2/2] migration_call(CPU_DEAD): use spin_lock_irq() instead of
task_rq_lock()
Diffed against 2.6.23-rc3
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
---
include/linux/cpuset.h |5 +
kernel/cpuset.c
te_lock_irq(tasklist)
[PATCH 2/2] migration_call(CPU_DEAD): use spin_lock_irq() instead of
task_rq_lock()
Diffed against 2.6.23-rc3
Signed-off-by: Cliff Wickman <[EMAIL PROTECTED]>
---
include/linux/cpuset.h |5 +
kernel/cpuset.c| 15 ++-
kernel/sched.c
Commit-ID: a26fd71953711acb4884df84e393d52de57e4f17
Gitweb: http://git.kernel.org/tip/a26fd71953711acb4884df84e393d52de57e4f17
Author: Cliff Wickman
AuthorDate: Wed, 14 May 2014 16:15:47 -0500
Committer: Ingo Molnar
CommitDate: Thu, 5 Jun 2014 14:17:20 +0200
x86/uv: Update the UV3 TLB
53 matches
Mail list logo
