Using spi_w8r16be() instead of spi_w8r16() in this driver makes a code a bit
shorter and cleaner.
Signed-off-by: Lars-Peter Clausen
---
drivers/hwmon/adt7310.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/hwmon/adt7310.c b/drivers/hwmon/adt7310.c
index
Hi,
On 27 September 2013 09:58, Ramkumar Ramachandra wrote:
> I'm interested in cross-compiling for ARM v8, and fixing some early
> papercuts to begin with; my host machine is a normal x86_64 box.
> Although I managed to use Linaro's toolchain [1] to build an Aarch64
> kernel, and found a
We fail build with NO_DEMANGLE with missing -lbfd externals error.
The reason is that we now use bfd code in srcline object:
perf tools: Implement addr2line directly using libbfd
So we need to check/add -lbfd always now.
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: Ingo Molnar
Cc:
We're missing ifdef LIBAUDIT_SUPPORT condition check
for calling cmd_trace, otherwise the NO_LIBAUDIT=1
build fails.
Introduced by commit:
perf trace: Add 'trace' alias to 'perf trace'
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter
On Friday 27 September 2013 02:36:52, Javier Martinez Canillas wrote:
> The GPIO OMAP controller pins can be used as IRQ and GPIO
> independently so is necessary to keep track GPIO pins and
> IRQ lines usage separately to make sure that the bank will
> always be enabled while being used.
>
> Also
On Fri, Sep 27, 2013 at 07:14:17AM -0700, Joe Perches wrote:
> Peter Zijlstra prefers that comments be required near uses
> of memory barriers.
>
> Change the message level for memory barrier uses from a
> --strict test only to a normal WARN so it's always emitted.
>
> This might produce false
On Thu, Sep 26, 2013 at 2:48 PM, Laxman Dewangan wrote:
> Recent movement of all configurations of pin in the single call of
> pin_config_set(), it is aborting configuration if BIAS_PULL_PIN_DEFAULT
> is selected as return of configuration.
>
> The original idea was to just avoid any update on
On Thu, Sep 26, 2013 at 10:32:06PM +0200, Borislav Petkov wrote:
> On Thu, Sep 26, 2013 at 04:20:59PM -0300, Eduardo Habkost wrote:
> > Please point me to the code that does this, because I don't see it on
> > patch 6/6.
>
> @@ -1850,7 +1850,14 @@ static void filter_features_for_kvm(X86CPU *cpu)
On 09/27/2013 06:59 PM, Will Deacon wrote:
> On Fri, Sep 27, 2013 at 09:04:46AM +0100, Jiang Liu wrote:
>> From: Jiang Liu
>>
>> Use PF_USED_MATH flag to mark whether the thread has accessed any FPSIMD
>> registers, so we could avoid saving and restroing FPSIMD registers until
>> threads access
On Fri, Sep 27, 2013 at 07:05:00AM -0700, Joe Perches wrote:
> On Fri, 2013-09-27 at 15:48 +0200, Peter Zijlstra wrote:
> > On Fri, Sep 27, 2013 at 06:44:55AM -0700, Joe Perches wrote:
> > > It's a CHK test, so it's only tested with --strict
> > >
> > > $ scripts/checkpatch.pl -f --strict
On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves
wrote:
> Some GPIO line limits are incorrectly set which, for instance,
> does not allow nRTS1 (GPH11) configuration on a S3C2416 chip.
>
> Signed-off-by: José Miguel Gonçalves
> ---
> arch/arm/mach-s3c24xx/include/mach/gpio.h | 10
On 09/26/2013 12:01 PM, Michael Ellerman wrote:
> +int powernv_hwrng_present(void)
> +{
> + return __raw_get_cpu_var(powernv_rng) != NULL;
> +}
> +
> static unsigned long rng_whiten(struct powernv_rng *rng, unsigned long val)
> {
> unsigned long parity;
> @@ -42,6 +48,17 @@ static
Peter Zijlstra prefers that comments be required near uses
of memory barriers.
Change the message level for memory barrier uses from a
--strict test only to a normal WARN so it's always emitted.
This might produce false positives around insertions of
memory barriers when a comment is outside the
On Fri, 2013-09-27 at 15:48 +0200, Peter Zijlstra wrote:
> On Fri, Sep 27, 2013 at 06:44:55AM -0700, Joe Perches wrote:
> > It's a CHK test, so it's only tested with --strict
> >
> > $ scripts/checkpatch.pl -f --strict kernel/mutex.c 2>&1 | grep memory
> > CHECK: memory barrier without comment
>
On Fri, Sep 27 2013, Robert Baldyga wrote:
> This patch add missing error check in ffs_func_bind() function, after
> ffs_do_descs() funcion call for hs descriptors. Without this check it's
> possible that the module will try dereference incorrect pointer.
>
> Signed-off-by: Robert Baldyga
On Fri, Sep 27, 2013 at 08:25:14AM -0500, Nishanth Menon wrote:
> As documented in Application Note SWPA117 v2.1(NDA), LDO override has a
> requirement that when switching from Bias active + override active
> mode(FBB/RBB) to Bypass(nominal) mode, LDO reset must be performed
> *after* LDO
On Fri, Sep 27, 2013 at 08:25:13AM -0500, Nishanth Menon wrote:
> On platforms like OMAP4460, LDO override is never used. Even though
> efuse determines the ABB bias mode to operate at, ABB voltage is
> preconfigured in internal efuse registers without the need for
> LDO override for bias voltage.
On 09/27/2013 12:47 AM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler wrote:
On 09/26/2013 03:53 PM, Miklos Szeredi wrote:
On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote:
But I'm not sure it's worth the effort; 99% of the use of this
interface will be copying whole
On Wed, 25 Sep 2013, Ingo Molnar wrote:
> >
> > I think this is necessary since it seems that the discussions on how to
> > do the raw_cpu conversions may take some time. If we enable it by
> > default then there will be numerous new log messages. That way a
> > developer can enable it for
On Thu, Sep 26, 2013 at 2:48 PM, Laxman Dewangan wrote:
> Palmas pinmux and pin configuration support the single pin level
> configuration in place of pin group.
>
> Hence it is only require to pin_config_{set|get} and do not require
> pin_config_group_{set|get}. As core framework already check
Em Fri, 27 Sep 2013 12:34:58 +0100
Mark Rutland escreveu:
> On Fri, Sep 27, 2013 at 10:33:11AM +0100, Srinivas KANDAGATLA wrote:
> > From: Srinivas Kandagatla
> >
> > This patch attempts to collate generic bindings which can be used by
> > the remote control hardwares. Currently the list is
Em Fri, 27 Sep 2013 14:26:12 +0100
Srinivas KANDAGATLA escreveu:
> On 27/09/13 12:34, Mark Rutland wrote:
>
> >> > +- rx-mode: Can be "infrared" or "uhf". rx-mode should be
> >> > present iff
> >> > + the rx pins are wired up.
> > I'm unsure on this. What if the device has
On Tue, Sep 24, 2013 at 5:04 PM, Mateusz Krawczuk
wrote:
> Values of pins in table s5pv210 bank are incorrect. This patch correct values.
>
> Signed-off-by: Mateusz Krawczuk
> Signed-off-by: Kyungmin Park
Patch applied for fixes with the ACKs from Tomasz and Kukjin.
Yours,
Linus Walleij
--
Hey,
On Thu, Sep 26, 2013 at 04:44:33PM -0700, Greg KH wrote:
> I seem to remember some issues here as well, probably with scsi devices,
> that kept us from doing this in this manner. Can you test this on
> removing some scsi devices and see if everything still works properly
> with this
On Fri, Sep 27, 2013 at 3:20 PM, Laxman Dewangan wrote:
> On Friday 27 September 2013 06:10 PM, Linus Walleij wrote:
>>
>> On Tue, Sep 24, 2013 at 7:47 PM, Laxman Dewangan
>> wrote:
>>
>>> function which just return not supported.
>>> - Nit cleanups.
>>
>> This is getting a lot better quickly.
On Fri, Sep 27, 2013 at 06:44:55AM -0700, Joe Perches wrote:
> It's a CHK test, so it's only tested with --strict
>
> $ scripts/checkpatch.pl -f --strict kernel/mutex.c 2>&1 | grep memory
> CHECK: memory barrier without comment
> CHECK: memory barrier without comment
>
> It could be changed to
Linus,
please pull sound fixes for v3.12-rc3 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.12
The topmost commit is 1bb3e062d4006bda733e8a0023b83f90700f663f
sound fixes for 3.12-rc3
Nothing
There are three callers of task_numa_fault():
- do_huge_pmd_numa_page():
Accounts against the current node, not the node where the
page resides, unless we migrated, in which case it accounts
against the node we migrated to.
- do_numa_page():
Accounts against the current
From: Peter Zijlstra
So I have the below patch in front of all your patches. It contains the
10 or so sched,fair patches I posted to lkml the other day.
I used these to poke at the group_imb crud, am now digging through
traces of perf bench numa to see if there's anything else I need.
like
Signed-off-by: Mel Gorman
---
Documentation/sysctl/kernel.txt | 66 +
1 file changed, 66 insertions(+)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index ab7d16e..ccadb52 100644
--- a/Documentation/sysctl/kernel.txt
+++
PTE scanning and NUMA hinting fault handling is expensive so commit
5bca2303 ("mm: sched: numa: Delay PTE scanning until a task is scheduled
on a new node") deferred the PTE scan until a task had been scheduled on
another node. The problem is that in the purely shared memory case that
this may
From: Peter Zijlstra
Avoiding marking PTEs pte_numa because a particular NUMA node is migrate rate
limited sees like a bad idea. Even if this node can't migrate anymore other
nodes might and we want up-to-date information to do balance decisions.
We already rate limit the actual migrations, this
THP migration uses the page lock to guard against parallel allocations
but there are cases like this still open
Task A Task B
do_huge_pmd_numa_page do_huge_pmd_numa_page
lock_page
mpol_misplaced == -1
unlock_page
goto
NUMA PTE scanning is expensive both in terms of the scanning itself and
the TLB flush if there are any updates. The TLB flush is avoided if no
PTEs are updated but there is a bug where transhuge PMDs are considered
to be updated even if they were already pmd_numa. This patch addresses
the problem
On 27-09-2013 09:26, Nishanth Menon wrote:
> On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
> wrote:
>> On 27-09-2013 08:24, Nishanth Menon wrote:
>>> On 23:13-20130926, Eduardo Valentin wrote:
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will
A THP PMD update is accounted for as 512 pages updated in vmstat. This is
large difference when estimating the cost of automatic NUMA balancing and
can be misleading when comparing results that had collapsed versus split
THP. This patch addresses the accounting issue.
Signed-off-by: Mel Gorman
On Fri, 2013-09-27 at 13:23 +0200, Peter Zijlstra wrote:
> checkpatch.pl should really warn about that; and it appears there
> code in there for that; however:
>
> # grep -C3 smp_mb scripts/checkpatch.pl
[]
> # check for memory barriers without a comment.
> if ($line =~
>
From: Peter Zijlstra
Fix a 80 column violation and a PTE vs PMD reference.
Signed-off-by: Peter Zijlstra
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 8
mm/huge_memory.c| 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c
The zero page is not replicated between nodes and is often shared between
processes. The data is read-only and likely to be cached in local CPUs
if heavily accessed meaning that the remote memory access cost is less
of a concern. This patch prevents trapping faults on the zero pages. For
tasks
From: Peter Zijlstra
With a trace_printk("working\n"); right after the cmpxchg in
task_numa_work() we can see that of a 4 thread process, its always the
same task winning the race and doing the protection change.
This is a problem since the task doing the protection change has a
penalty for
This patch favours moving tasks towards NUMA node that recorded a higher
number of NUMA faults during active load balancing. Ideally this is
self-reinforcing as the longer the task runs on that node, the more faults
it should incur causing task_numa_placement to keep the task running on that
task_numa_placement checks current->mm but after buffers for faults
have already been uselessly allocated. Move the check earlier.
[pet...@infradead.org: Identified the problem]
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
The locking for migrating THP is unusual. While normal page migration
prevents parallel accesses using a migration PTE, THP migration relies on
a combination of the page_table_lock, the page lock and the existance of
the NUMA hinting PTE to guarantee safety but there is a bug in the scheme.
If a
Scan delay logic and resets are currently initialised to start scanning
immediately instead of delaying properly. Initialise them properly at
fork time and catch when a new mm has been allocated.
Signed-off-by: Mel Gorman
---
kernel/sched/core.c | 4 ++--
kernel/sched/fair.c | 7 +++
2
NUMA PTE scanning slows if a NUMA hinting fault was trapped and no page
was migrated. For long-lived but idle processes there may be no faults
but the scan rate will be high and just waste CPU. This patch will slow
the scan rate for processes that are not trapping faults.
Signed-off-by: Mel
There is a 90% regression observed with a large Oracle performance test
on a 4 node system. Profiles indicated that the overhead was due to
contention on sp_lock when looking up shared memory policies. These
policies do not have the appropriate flags to allow them to be
automatically balanced so
NUMA hinting fault counts and placement decisions are both recorded in the
same array which distorts the samples in an unpredictable fashion. The values
linearly accumulate during the scan and then decay creating a sawtooth-like
pattern in the per-node counts. It also means that placement
task_numa_work skips small VMAs. At the time the logic was to reduce the
scanning overhead which was considerable. It is a dubious hack at best.
It would make much more sense to cache where faults have been observed
and only rescan those regions during subsequent PTE scans. Remove this
hack as
A preferred node is selected based on the node the most NUMA hinting
faults was incurred on. There is no guarantee that the task is running
on that node at the time so this patch rescheules the task to run on
the most idle CPU of the selected node when selected. This avoids
waiting for the
Ideally it would be possible to distinguish between NUMA hinting faults
that are private to a task and those that are shared. This patch prepares
infrastructure for separately accounting shared and private faults by
allocating the necessary buffers and passing in relevant information. For
now,
NUMA PTE scanning is expensive both in terms of the scanning itself and
the TLB flush if there are any updates. Currently non-present PTEs are
accounted for as an update and incurring a TLB flush where it is only
necessary for anonymous migration entries. This patch addresses the
problem and
THP migrations are serialised by the page lock but on its own that does
not prevent THP splits. If the page is split during THP migration then
the pmd_same checks will prevent page table corruption but the unlock page
and other fix-ups potentially will cause corruption. This patch takes the
The NUMA PTE scan rate is controlled with a combination of the
numa_balancing_scan_period_min, numa_balancing_scan_period_max and
numa_balancing_scan_size. This scan rate is independent of the size
of the task and as an aside it is further complicated by the fact that
numa_balancing_scan_size
Currently automatic NUMA balancing is unable to distinguish between false
shared versus private pages except by ignoring pages with an elevated
page_mapcount entirely. This avoids shared pages bouncing between the
nodes whose task is using them but that is ignored quite a lot of data.
This patch
Just as "sched: Favour moving tasks towards the preferred node" favours
moving tasks towards nodes with a higher number of recorded NUMA hinting
faults, this patch resists moving tasks towards nodes with lower faults.
[mgor...@suse.de: changelog]
Signed-off-by: Peter Zijlstra
Signed-off-by: Mel
This patch selects a preferred node for a task to run on based on the
NUMA hinting faults. This information is later used to migrate tasks
towards the node during balancing.
Signed-off-by: Mel Gorman
---
include/linux/sched.h | 1 +
kernel/sched/core.c | 1 +
kernel/sched/fair.c | 17
From: Peter Zijlstra
Introduce stop_two_cpus() in order to allow controlled swapping of two
tasks. It repurposes the stop_machine() state machine but only stops
the two cpus which we can do with on-stack structures and avoid
machine wide synchronization issues.
The ordering of CPUs is important
Ideally it would be possible to distinguish between NUMA hinting faults that
are private to a task and those that are shared. If treated identically
there is a risk that shared pages bounce between nodes depending on
the order they are referenced by tasks. Ultimately what is desirable is
that task
It is desirable to model from userspace how the scheduler groups tasks
over time. This patch adds an ID to the numa_group and reports it via
/proc/PID/status.
Signed-off-by: Mel Gorman
---
fs/proc/array.c | 2 ++
include/linux/sched.h | 5 +
kernel/sched/fair.c | 7 +++
3 files
This patch implements a system-wide search for swap/migration candidates
based on total NUMA hinting faults. It has a balance limit, however it
doesn't properly consider total node balance.
In the old scheme a task selected a preferred node based on the highest
number of private faults recorded
From: Rik van Riel
The load balancer can move tasks between nodes and does not take NUMA
locality into account. With automatic NUMA balancing this may result in the
tasks working set being migrated to the new node. However, as the fault
buffer will still store faults from the old node the
From: Peter Zijlstra
Use the new stop_two_cpus() to implement migrate_swap(), a function that
flips two tasks between their respective cpus.
I'm fairly sure there's a less crude way than employing the stop_two_cpus()
method, but everything I tried either got horribly fragile and/or complex. So
From: Peter Zijlstra
Change the per page last fault tracking to use cpu,pid instead of
nid,pid. This will allow us to try and lookup the alternate task more
easily. Note that even though it is the cpu that is store in the page
flags that the mpol_misplaced decision is still based on the node.
On 09/26/2013 05:50 AM, Thierry Reding wrote:
> On Thu, Sep 26, 2013 at 03:26:13PM +0300, Tomi Valkeinen wrote:
>> On 26/09/13 15:02, Thierry Reding wrote:
>>> On Thu, Sep 26, 2013 at 01:13:18PM +0300, Tomi Valkeinen wrote:
On 11/09/13 14:40, Mike Dunn wrote:
> On 09/10/2013 10:21 AM,
From: Peter Zijlstra
While parallel applications tend to align their data on the cache
boundary, they tend not to align on the page or THP boundary.
Consequently tasks that partition their data can still "false-share"
pages presenting a problem for optimal NUMA placement.
This patch uses NUMA
From: Rik van Riel
The load balancer will spread workloads across multiple NUMA nodes,
in order to balance the load on the system. This means that sometimes
a task's preferred node has available capacity, but moving the task
there will not succeed, because that would create too large an
This patch replaces find_idlest_cpu_node with task_numa_find_cpu.
find_idlest_cpu_node has two critical limitations. It does not take the
scheduling class into account when calculating the load and it is unsuitable
for using when comparing loads between NUMA nodes.
task_numa_find_cpu uses similar
From: Ingo Molnar
Signed-off-by: Ingo Molnar
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-5giqjcqnc93a89q01ymtj...@git.kernel.org
---
include/linux/sched.h | 6 ++
kernel/sched/debug.c | 60 +--
kernel/sched/fair.c |
When a preferred node is selected for a tasks there is an attempt to migrate
the task to a CPU there. This may fail in which case the task will only
migrate if the active load balancer takes action. This may never happen if
the conditions are not right. This patch will check at NUMA hinting fault
From: Rik van Riel
It is possible for a task in a numa group to call exec, and
have the new (unrelated) executable inherit the numa group
association from its former self.
This has the potential to break numa grouping, and is trivial
to fix.
Signed-off-by: Rik van Riel
Signed-off-by: Mel
This patch uses the fraction of faults on a particular node for both task
and group, to figure out the best node to place a task. If the task and
group statistics disagree on what the preferred node should be then a full
rescan will select the node with the best combined weight.
Signed-off-by:
From: Rik van Riel
A newly spawned thread inside a process should stay on the same
NUMA node as its parent. This prevents processes from being "torn"
across multiple NUMA nodes every time they spawn a new thread.
Signed-off-by: Rik van Riel
Signed-off-by: Mel Gorman
---
include/linux/sched.h
From: Rik van Riel
After page migration, the new page has the nidpid unset. This makes
every fault on a recently migrated page look like a first numa fault,
leading to another page migration.
Copying over the nidpid at page migration time should prevent erroneous
migrations of recently migrated
Having multiple tasks in a group go through task_numa_placement
simultaneously can lead to a task picking a wrong node to run on, because
the group stats may be in the middle of an update. This patch avoids
parallel updates by holding the numa_group lock during placement
decisions.
Signed-off-by:
* Borislav Petkov wrote:
> On Fri, Sep 27, 2013 at 08:51:15AM +0200, Ingo Molnar wrote:
> > That message was cool and interesting back in the days when we wrote
> > lockdep ('hey, look ma, it really works!!'), but there hasn't been
> > any breakage in that area for a long time and it definitely
With the THP migration races closed it is still possible to occasionally
see corruption. The problem is related to handling PMD pages in batch.
When a page fault is handled it can be assumed that the page being
faulted will also be flushed from the TLB. The same flushing does not
happen when
Hi
With recent build of 3.12-rc2 I'm getting this warning report from kernel:
(hw Lenovo T61, C2D, 4GB Ram)
(repost since linux-kernel@ rejected my gmail email)
e1000e :00:19.0: irq 46 for MSI/MSI-X
[ cut here ]
WARNING: CPU: 1 PID: 301 at fs/sysfs/dir.c:526
From: Rik van Riel
This patch separately considers task and group affinities when
searching for swap candidates during NUMA placement. If tasks
are part of the same group, or no group at all, the task weights
are considered.
Some hysteresis is added to prevent tasks within one group from
Scan rate is altered based on whether shared/private faults dominated.
task_numa_group() may detect false sharing but that information is not
taken into account when adapting the scan rate. Take it into account.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 8 ++--
1 file changed, 6
From: Rik van Riel
This patch separately considers task and group affinities when searching
for swap candidates during task NUMA placement. If tasks are not part of
a group or the same group then the task weights are considered.
Otherwise the group weights are compared.
Signed-off-by: Rik van
Hi Jason,
On 09/18/2013 10:32 PM, Jason Gunthorpe wrote:
> On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
>
>> + Jason Gunthorpe
>
> Thanks, looks interesting, we could possibly use this interface if it
> met our needs..
>
>> On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal
With scan rate adaptions based on whether the workload has properly
converged or not there should be no need for the scan period reset
hammer. Get rid of it.
Signed-off-by: Mel Gorman
---
Documentation/sysctl/kernel.txt | 11 +++
include/linux/mm_types.h| 3 ---
Am 27.09.2013 14:51, schrieb Richard Genoud:
> The test:
> if (!a && b)
> a = b;
> can be symplified in:
> if (!a)
> a = b;
>
> And there's no need to test if ubi->image_seq is not null, because if it is,
> it is set to image_seq.
> So, we just test if image_seq is not null.
>
>
NUMA hinting faults will not migrate a shared executable page mapped by
multiple processes on the grounds that the data is probably in the CPU
cache already and the page may just bounce between tasks running on multipl
nodes. Even if the migration is avoided, there is still the overhead of
From: Rik van Riel
With the scan rate code working (at least for multi-instance specjbb),
the large hammer that is "sched: Do not migrate memory immediately after
switching node" can be replaced with something smarter. Revert temporarily
migration disabling and all traces of numa_migrate_seq.
As Peter says "If you're going to hold locks you can also do away with all
that atomic_long_*() nonsense". Lock aquisition moved slightly to protect
the updates.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 49 -
1 file changed, 20
From: Rik van Riel
Adjust numa_scan_period in task_numa_placement, depending on how much
useful work the numa code can do. The more local faults there are in a
given scan window the longer the period (and hence the slower the scan rate)
during the next window. If there are excessive shared
From: Rik van Riel
Shared faults can lead to lots of unnecessary page migrations,
slowing down the system, and causing private faults to hit the
per-pgdat migration ratelimit.
This patch adds sysctl numa_balancing_migrate_deferred, which specifies
how many shared page migrations to skip
From: Rik van Riel
Due to the way the pid is truncated, and tasks are moved between
CPUs by the scheduler, it is possible for the current task_numa_fault
to group together tasks that do not actually share memory together.
This patch adds a few easy sanity checks to task_numa_fault, joining
From: Peter Zijlstra
(This changelog needs more work, it's currently inaccurate and it's not
clear at exactly what point rt > env->fbq_type is true for the logic to
kick in)
This patch classifies scheduler domains and runqueues into FBQ (cannot
guess what this expands to) types which are one of
From: Peter Zijlstra
And here's a little something to make sure not the whole world ends up
in a single group.
As while we don't migrate shared executable pages, we do scan/fault on
them. And since everybody links to libc, everybody ends up in the same
group.
[r...@redhat.com: mapcount 1]
Base page PMD faulting is meant to batch handle NUMA hinting faults from
PTEs. However, even is no PTE faults would ever be handled within a
range the kernel still traps PMD hinting faults. This patch avoids the
overhead.
Signed-off-by: Mel Gorman
---
mm/mprotect.c | 7 +--
1 file changed,
A tasks preferred node is selected based on the number of faults
recorded for a node but the actual task_numa_migate() conducts a global
search regardless of the preferred nid. This patch checks if the
preferred nid has capacity and if so, searches for a CPU within that
node. This avoids a global
This patch tracks what nodes numa hinting faults were incurred on.
This information is later used to schedule a task on the node storing
the pages most frequently faulted by the task.
Signed-off-by: Mel Gorman
---
include/linux/sched.h | 2 ++
kernel/sched/core.c | 3 +++
From: Rik van Riel
When a task is already running on its preferred node, increment
numa_migrate_seq to indicate that the task is settled if migration is
temporarily disabled, and memory should migrate towards it.
[mgor...@suse.de: Only increment migrate_seq if migration temporarily disabled]
On 27/09/13 12:34, Mark Rutland wrote:
>> > + - rx-mode: Can be "infrared" or "uhf". rx-mode should be present iff
>> > +the rx pins are wired up.
> I'm unsure on this. What if the device has multiple receivers that can
> be independently configured? What if it supports something other than
From: Rik van Riel
Short spikes of CPU load can lead to a task being migrated
away from its preferred node for temporary reasons.
It is important that the task is migrated back to where it
belongs, in order to avoid migrating too much memory to its
new location, and generally disturbing a
Weighing in at 63 patches makes the term "basic" in the series title is
a misnomer.
This series still has roughly the same goals as previous versions. It
reduces overhead of automatic balancing through scan rate reduction
and the avoidance of TLB flushes. It selects a preferred node and moves
If another task handled a hinting fault in parallel then do not double
account for it.
Not-signed-off-by: Peter Zijlstra
---
mm/huge_memory.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 860a368..5c37cd2 100644
---
On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
wrote:
> On 27-09-2013 08:24, Nishanth Menon wrote:
>> On 23:13-20130926, Eduardo Valentin wrote:
>>> This patch changes the dtsi entry on omap4430 to contain
>>> the thermal data. This data will enable the passive
>>> cooling with CPUfreq cooling
301 - 400 of 1156 matches
Mail list logo
