-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/15/2015 02:20 PM, Oleg Nesterov wrote:
> Now that we have in_kernel_fpu we can remove
> __thread_clear_has_fpu() in __kernel_fpu_begin(). And this allows
> to replace the asymmetrical and nontrivial use_eager_fpu +
> tsk_used_math check in kernel
atch also moves WARN_ON_ONCE() under preempt_disable() just
> to make this_cpu_read() look better, this is not really needed. And
> in fact I think we should move it into __kernel_fpu_begin().
>
> Signed-off-by: Oleg Nesterov
Reviewed-by: Rik van Riel
On 01/15/2015 05:45 AM, Peter Zijlstra wrote:
On Mon, Jan 12, 2015 at 04:30:39PM -0500, Rik van Riel wrote:
There is a subtle interaction between the logic introduced in commit
e63da03639cc9e6e83b62e7ef8ffdbb92421416a, the way the load balancer
e63da03639cc ("sched/numa: Allow task s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/14/2015 01:36 PM, Oleg Nesterov wrote:
> On 01/11, r...@redhat.com wrote:
>>
>> If the next task still has its FPU state present in the FPU
>> registers, there is no need to restore it from memory.
>
> Another patch I can't understand...
>
>>
On 01/14/2015 12:12 PM, Marcelo Tosatti wrote:
> Since lapic timer handler only wakes up a simple waitqueue,
> it can be executed from hardirq context.
>
> Reduces average cyclictest latency by 3us.
>
> Signed-off-by: Marcelo Tosatti
Acked-by: Rik van Riel
--
To unsubscr
xtra context switch introduces unnecessary latency in the
> LAPIC path for a KVM guest.
> This patch reduces the average latency in my tests from 14us to 11us.
>
> Signed-off-by: Marcelo Tosatti
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 12:11 PM, Andy Lutomirski wrote:
> On Sun, Jan 11, 2015 at 1:46 PM, wrote:
>> diff --git a/arch/x86/include/asm/fpu-internal.h
>> b/arch/x86/include/asm/fpu-internal.h index 4db8781..a5a40c7
>> 100644 --- a/arch/x86/include/asm/fpu-int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 01:30 PM, Oleg Nesterov wrote:
> On 01/13, Oleg Nesterov wrote:
>>
>> But yes, I think we need the per-cpu "in_kernel_fpu" and
>> irq_fpu_usable() must die. Please look at
>> http://marc.info/?l=linux-kernel&m=14096628660929
This link d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 12:58 PM, Oleg Nesterov wrote:
> On 01/11, r...@redhat.com wrote:
>>
>> Defer restoring the FPU state, if so desired, until the task
>> returns to userspace.
>
> And yet another concern ;) Although I feel that I am totally
> confused an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 12:57 PM, Andy Lutomirski wrote:
> On Tue, Jan 13, 2015 at 9:44 AM, Rik van Riel
> wrote: On 01/13/2015 12:18 PM, Andy Lutomirski wrote:
>>>> - Task is not current and FPU is in memory. - Task is not
>>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 12:11 PM, Oleg Nesterov wrote:
> On 01/11, r...@redhat.com wrote:
>>
>> Defer restoring the FPU state, if so desired, until the task
>> returns to userspace.
>
> And I have another concern.
>
> Afaocs with this patch the idle threads w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 12:18 PM, Andy Lutomirski wrote:
> On Tue, Jan 13, 2015 at 9:11 AM, Oleg Nesterov
> wrote:
>> On 01/11, r...@redhat.com wrote:
>>>
>>> Defer restoring the FPU state, if so desired, until the task
>>> returns to userspace.
>>
>> And I h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 11:50 AM, Oleg Nesterov wrote:
> On 01/13, Rik van Riel wrote:
>>
>>>> @@ -412,8 +412,14 @@ static inline void
>>>> switch_fpu_prepare(struct task_struct *old, struct task_struc
>>>> bool p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 10:24 AM, Oleg Nesterov wrote:
> On 01/11, r...@redhat.com wrote:
>>
>> --- a/arch/x86/include/asm/fpu-internal.h +++
>> b/arch/x86/include/asm/fpu-internal.h @@ -420,7 +420,6 @@ static
>> inline void switch_fpu_prepare(struct task_struc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 10:24 AM, Oleg Nesterov wrote:
> Rik,
>
> I can't review this series, I forgot almost everything I learned
> about this code. The only thing I can recall is that it needs
> cleanups and fixes ;) Just a couple of random questions.
>
> On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2015 11:19 AM, Oleg Nesterov wrote:
> On 01/11, r...@redhat.com wrote:
>>
>> @@ -412,8 +412,14 @@ static inline void switch_fpu_prepare(struct
>> task_struct *old, struct task_struc bool preload =
>> tsk_used_math(new) && (use_eager_fpu() ||
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2015 04:52 PM, Dave Hansen wrote:
> On 01/11/2015 01:46 PM, r...@redhat.com wrote:
>> +/* + * The FPU state used depends on the capabilities of the
>> hardware; the + * registers used for vector instructions on newer
>> hardware are included +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/09/2015 09:51 PM, David Lang wrote:
> On Fri, 9 Jan 2015, Linus Torvalds wrote:
>
>> Big pages are a bad bad bad idea. They work fine for databases,
>> and that's pretty much just about it. I'm sure there are some
>> other loads, but they are fe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2015 04:18 PM, Borislav Petkov wrote:
> On Sun, Jan 11, 2015 at 04:46:23PM -0500, r...@redhat.com wrote:
>> +++ b/arch/x86/include/asm/processor.h @@ -400,6 +400,11 @@
>> struct xsave_struct { /* new processor state extensions will go
>> here
em to move past the point
of balance. In an unbalanced state, only moves that bring us closer
to the balance point are allowed.
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/kernel/
->anon_vma before calling anon_vma_clone().
>
> Signed-off-by: Konstantin Khlebnikov Fixes:
> 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy")
> Tested-by: Chris Clayton Tested-by: Oded
> Gabbay Cc: Daniel Forrest
> Cc: Michal Hocko Cc:
> Rik
t; intentional.
>
> Thus, replace wake_up() with wake_up_all().
>
> Signed-off-by: Vlastimil Babka Cc: Mel Gorman
> Cc: Johannes Weiner Cc:
> Michal Hocko Cc: Vladimir Davydov
> Cc: Rik van Riel
Acked-by: Rik van Riel
- --
All rights reversed
-BEGIN PG
Mel Gorman
> Cc: Johannes Weiner Cc:
> Michal Hocko Cc: Rik van Riel
Acked-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUq0xLAAoJEM553pKExN6D8ZgH/3AjsMKmA/JytTf5WOjpO0+W
ozN7ttYjYfIAFytYymPYkbm5/8pLBhy9HM9szMijRa+vhL
fies, base->timer_jiffies)) { +unsigned
> long jiffies_delta = jiffies - base->timer_jiffies; + if
> (jiffies_delta > TVR_SIZE) + raise_softirq(TIMER_SOFTIRQ); +
> }
It certainly looks like cascading the timers over and over and
over again
1 linux-next
>
> Signed-off-by: Nicholas Mc Guire
Reviewed-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUnCJVAAoJEM553pKExN6DTl4IALfePxNFoRphS8CmLbONtqmi
Bs4gu9ngJq6BLenk6bOF5wfMCRTBXHagWnn14wrjjZOFBkh9Fh+Zy+8GKS31rwUL
GNsCdOUo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/23/2014 03:47 PM, Khalid Aziz wrote:
>> You are right. Uncontended futex is very fast since it never goes
>> into kernel. Queuing problem happens when the lock holder has
>> been pre-empted. Adaptive spinning does the smart thing os
>> spin-wait
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/23/2014 10:13 AM, Khalid Aziz wrote:
> On 12/23/2014 03:52 AM, Ingo Molnar wrote:
>>
>>
>> to implement what Thomas suggested in the discussion: a proper
>> futex like spin mechanism? That looks like a totally acceptable
>> solution to me, wi
sn't reused even if was no alive vma, thus rmap walker has a good chance
> + * to avoid scanning whole hieraryhy when it searches where page is mapped.
^
hierarchy
Other than that:
Reviewed-by: Rik van Riel
Thanks for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/10/2014 08:53 PM, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 5:32 PM, Rik van Riel
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 12/10/2014 07:51 PM, Andy Lutomirski wrote:
>>> On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/10/2014 07:51 PM, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 4:49 PM, Rik van Riel
> wrote: On 12/10/2014 07:46 PM, Daniel J Blueman wrote:
>>>> Gah. I had some non-temporal copy changes in the wrong tree.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/10/2014 07:46 PM, Daniel J Blueman wrote:
> Gah. I had some non-temporal copy changes in the wrong tree. I'll
> check with a definitely clean tree and follow up if it still
> occurs.
The exception handlers should definitely allow sleeping,
so I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/26/2014 01:11 PM, Konstantin Khlebnikov wrote:
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h index
> c0c2bce..b1d140c 100644 --- a/include/linux/rmap.h +++
> b/include/linux/rmap.h @@ -45,6 +45,22 @@ struct anon_vma { *
> mm_take_al
off-by: Marcelo Tosatti
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 11/25/2014 01:57 PM, Rik van Riel wrote:
> On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
>> The problem:
>>
>> On -RT, an emulated LAPIC timer instances has the following path:
>>
>> 1) hard interrupt
>> 2) ksoftirqd is scheduled
>> 3) ksofti
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
> The problem:
>
> On -RT, an emulated LAPIC timer instances has the following path:
>
> 1) hard interrupt
> 2) ksoftirqd is scheduled
> 3) ksoftirqd wakes up vcpu thread
> 4) vcpu thread is scheduled
>
> This extra context switch introduces unneces
On 11/25/2014 12:22 PM, Khalid Aziz wrote:
> On 11/25/2014 08:25 AM, Rik van Riel wrote:
>> On 11/25/2014 09:52 AM, Khalid Aziz wrote:
>>> On 11/24/2014 07:03 PM, Rik van Riel wrote:
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA1
>>&
On 11/25/2014 11:45 AM, Marcelo Tosatti wrote:
> Which allows waking up vcpu from hardirq context.
>
>
Changelog?
Why?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/m
On 11/25/2014 09:52 AM, Khalid Aziz wrote:
> On 11/24/2014 07:03 PM, Rik van Riel wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11/24/2014 03:56 PM, Khalid Aziz wrote:
>>> sched/fair: Add advisory flag for borrowing a timeslice
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/25/2014 01:30 AM, Davidlohr Bueso wrote:
> On Mon, 2014-11-24 at 21:03 -0500, Rik van Riel wrote:
>> I can see this "solution" help mostly with userspace spinlocks,
>> which are relics of a past era that nee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/2014 03:56 PM, Khalid Aziz wrote:
> sched/fair: Add advisory flag for borrowing a timeslice
>
> This patch adds a way for a task to request to borrow one
> timeslice from future if it is about to be preempted, so it could
> delay preemption a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/23/2014 01:23 PM, Manfred Spraul wrote:
> Hi Rik,
>
> On 11/21/2014 08:52 PM, Rik van Riel wrote:
>> When manipulating just one semaphore with semop, sem_lock only
>> takes that single semaphore's lock. Thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/22/2014 02:14 PM, Manfred Spraul wrote:
> On 11/21/2014 09:29 PM, Rik van Riel wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 11/21/2014 03:09 PM, Andrew Morton wrote:
>>> On Fri, 21 Nov 20
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/22/2014 08:56 AM, Manfred Spraul wrote:
> Hi Rik,
>
> good catch - I completely forgot to check the initialization
>
> On 11/22/2014 04:40 AM, Rik van Riel wrote:
>>
>> newary initializes a bunch of things
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/21/2014 07:56 PM, Davidlohr Bueso wrote:
> On Fri, 2014-11-21 at 18:03 -0500, Rik van Riel wrote:
>> In other words, if you try to use a semaphore array before getsem
>> returns, you can oops the task that calls semop.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/21/2014 03:42 PM, Andrew Morton wrote:
> On Fri, 21 Nov 2014 15:29:27 -0500 Rik van Riel
> wrote:
>
>> On 11/21/2014 03:09 PM, Andrew Morton wrote:
>>> On Fri, 21 Nov 2014 14:52:26 -0500 Rik van Riel
>>> w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/21/2014 03:09 PM, Andrew Morton wrote:
> On Fri, 21 Nov 2014 14:52:26 -0500 Rik van Riel
> wrote:
>
>> When manipulating just one semaphore with semop, sem_lock only
>> takes that single semaphore's lock. Thi
ocking
the sma->lock.
Signed-off-by: Rik van Riel
---
ipc/sem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index 454f6c6..1823160 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -507,6 +507,9 @@ static int newary(struct ipc_namespace *ns, struct
i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2014 09:42 AM, Konstantin Khlebnikov wrote:
> I'm thinking about limitation for reusing anon_vmas which might
> increase performance without breaking asymptotic estimation of
> count anon_vma in the worst case. For example this heuristic: all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 03:19 PM, Andrew Morton wrote:
> On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel
> wrote:
>
>> That way people can understand what the code does simply by
>> looking at the changelog - no need to go find old li
oding of number 5: could we make it a variable to tweak
>>>> with sysfs/sysctl so if some weird workload arises we have a
>>>> tuning tweak? It'd cost one cacheline during fork, so it
>>>> doesn't look excessive overhead.
>>>
>>> Ad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/14/2014 01:34 PM, Rafael Aquini wrote:
> Minor fixlet to perform the reserved pages counter aggregation for
> each node, at show_mem()
>
> Signed-off-by: Rafael Aquini
Acked-by: Rik van Riel
- --
All rights reversed
--
On 11/14/2014 08:08 AM, Michal Hocko wrote:
Hi,
back in 2012 [1] there was a discussion about a forking load which
accumulates anon_vmas. There was a trivial test case which triggers this
and can potentially deplete the memory by local user.
We have a report for an older enterprise distribution
On 11/10/2014 03:22 PM, Linus Torvalds wrote:
> Rik, the fact that you acked this just makes all your other ack's be
> suspect. Did you do it just because it was from Red Hat, or do you do
> it because you like seeing Acked-by's with your name?
I acked it because I could not come up with a better
v1: - Fixed all checkpatch.pl issue (ignoreing some
> over 80 characters).
>
> Changed since v2: - Rebase and adapted to lastest change.
>
> Signed-off-by: Jérôme Glisse
Acked-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGB
he core mm code of the linux kernel avoiding
> duplicate implementation and shielding device driver code from core
> mm code.
Acked-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUXTs9AAoJEM553pKExN6DhSYIAI41vr6c/vVdIg2m6Wq3DiSS
KtBTU
exiting from sched_init_numa() earlier.
>
> Signed-off-by: Andrey Ryabinin Fixes:
> 9942f79ba ("sched/numa: Export info needed for NUMA balancing on
> complex topologies")
Reviewed-by: Rik van Riel
> Another option would be to not call sched_init_numa() if
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/2014 05:40 PM, Jerome Glisse wrote:
> On Thu, Nov 06, 2014 at 05:32:00PM -0500, Rik van Riel wrote:
> Never a fan of preprocessor magic, but I see why it's needed.
>
> Acked-by: Rik van Riel
>
>> v1 is not us
here is no use for the extra flexibility v1 was
> offering.
>
> Signed-off-by: Jérôme Glisse
Never a fan of preprocessor magic, but I see why it's needed.
Acked-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgA
l not be added after the call to the
> helper function to query for existing range.
>
> Signed-off-by: Jérôme Glisse
Reviewed-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUW+IYAAoJEM553pKExN6DGQ0H/AsZ
range_start
> callback returns. Read + * access are still allowed.
After fixing the spelling mistake, feel free to add my
Reviewed-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUW6z0AAoJEM553pKExN6DN3wIALqZPmNihc/AbOc6MCnp+two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2014 06:37 AM, w00218164 wrote:
> From: Wei Yuan
>
> This patch fixes a spelling mistake in func __zone_watermark_ok,
> which may was wrongly spelled my.
>
> Signed-off-by Wei Yuan
Acked-by: Rik van Riel
- --
A
idx function so that it can return
> an index to the correct offset, corresponding with the old precalculated
> pointers.
>
> All of the code in sched/ that depended on task_faults_idx and numa_* was
> changed in order to match the new logic.
>
> Signed-off-by: Iulia Ma
On 10/28/2014 08:58 AM, Rik van Riel wrote:
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton writes:
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing
On 10/28/2014 08:12 AM, Andi Kleen wrote:
> Alex Thorlton writes:
>
>> Last week, while discussing possible fixes for some unexpected/unwanted
>> behavior
>> from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
>> mentioned possibly changing changing khugepaged to work as a
Commit-ID: 9de05d48711cd5314920ed05f873d84eaf66ccf1
Gitweb: http://git.kernel.org/tip/9de05d48711cd5314920ed05f873d84eaf66ccf1
Author: Rik van Riel
AuthorDate: Thu, 9 Oct 2014 17:27:47 -0400
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 10:47:52 +0100
sched/numa: Check all nodes
Commit-ID: 7bd953206b0b5e0a3aded871982367410b42e1b1
Gitweb: http://git.kernel.org/tip/7bd953206b0b5e0a3aded871982367410b42e1b1
Author: Rik van Riel
AuthorDate: Fri, 17 Oct 2014 03:29:51 -0400
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 10:47:49 +0100
sched/numa: Prepare for
Commit-ID: 6c6b1193e71fed1a58dc3fab9d967d245177f87b
Gitweb: http://git.kernel.org/tip/6c6b1193e71fed1a58dc3fab9d967d245177f87b
Author: Rik van Riel
AuthorDate: Fri, 17 Oct 2014 03:29:52 -0400
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 10:47:50 +0100
sched/numa: Calculate node
Commit-ID: e3fe70b1f72e3f83a00d9c332ec09ab347a981e2
Gitweb: http://git.kernel.org/tip/e3fe70b1f72e3f83a00d9c332ec09ab347a981e2
Author: Rik van Riel
AuthorDate: Fri, 17 Oct 2014 03:29:50 -0400
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 10:47:48 +0100
sched/numa: Classify the
Commit-ID: 54009416ac3b5f219c0df68559ce534287ae97b1
Gitweb: http://git.kernel.org/tip/54009416ac3b5f219c0df68559ce534287ae97b1
Author: Rik van Riel
AuthorDate: Fri, 17 Oct 2014 03:29:53 -0400
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 10:47:51 +0100
sched/numa: Find the
Commit-ID: 9942f79baaaf111d63ebf0862a819278d84fccc4
Gitweb: http://git.kernel.org/tip/9942f79baaaf111d63ebf0862a819278d84fccc4
Author: Rik van Riel
AuthorDate: Fri, 17 Oct 2014 03:29:49 -0400
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 10:47:47 +0100
sched/numa: Export info
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2014 10:49 PM, Alex Thorlton wrote:
> Alex Thorlton (4): Disable khugepaged thread Add pgcollapse
> controls to task_struct Convert khugepaged scan functions to work
> with task_work Add /proc files to expose per-mm pgcollapse stats
Is it ju
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2014 10:12 PM, Mike Galbraith wrote:
> On Wed, 2014-10-22 at 21:42 -0400, Rik van Riel wrote:
>> On 10/22/2014 07:20 PM, Mike Turquette wrote:
>>> On Wed, Oct 22, 2014 at 1:06 PM, Rik van Riel
>>> wrote: O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2014 07:20 PM, Mike Turquette wrote:
> On Wed, Oct 22, 2014 at 1:06 PM, Rik van Riel
> wrote: On 10/22/2014 02:07 AM, Mike Turquette wrote:
>>>> arch_eval_cpu_freq and arch_scale_cpu_freq are added to allow
>>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2014 02:07 AM, Mike Turquette wrote:
> arch_eval_cpu_freq and arch_scale_cpu_freq are added to allow the
> scheduler to evaluate if cpu frequency should change and to invoke
> that change from a safe context.
>
> They are weakly defined arch
m
Cc: Mel Gorman
Cc: Joonsoo Kim
Cc: Michal Nazarewicz
Cc: Naoya Horiguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
d-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
iguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
: Mel Gorman
Cc: Joonsoo Kim
Cc: Michal Nazarewicz
Cc: Naoya Horiguchi
Cc: Christoph Lameter
Cc: Rik van Riel
Cc: David Rientjes
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
On 10/14/2014 10:54 AM, Peter Zijlstra wrote:
On Tue, Oct 14, 2014 at 02:48:28PM +0300, Kirill A. Shutemov wrote:
Why whould you want to pin khugpeaged? Is there a valid use-case?
Looks like userspace shoots to its leg.
Its just bad design to put so much work in another context. But the
use-c
On 10/14/2014 02:47 AM, Peter Zijlstra wrote:
On Sun, Oct 12, 2014 at 09:28:04AM -0400, Rik van Riel wrote:
On 10/12/2014 09:17 AM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:37:26PM -0400, r...@redhat.com wrote:
+ sched_domains_numa_hops = kzalloc(sizeof(int) * nr_node_ids
On 10/12/2014 10:56 AM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:37:30PM -0400, r...@redhat.com wrote:
+static int preferred_group_nid(struct task_struct *p, int nid)
+{
+ nodemask_t nodes;
+ int hops;
+
+ /* Direct connections between all NUMA nodes. */
+ if (sch
On 10/12/2014 10:53 AM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:37:29PM -0400, r...@redhat.com wrote:
From: Rik van Riel
In order to do task placement on systems with complex NUMA topologies,
it is necessary to count the faults on nodes nearby the node that is
being examined for a
On 10/12/2014 10:37 AM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:37:28PM -0400, r...@redhat.com wrote:
From: Rik van Riel
Preparatory patch for adding NUMA placement on systems with
complex NUMA topology. Also fix a potential divide by zero
in group_weight()
Signed-off-by: Rik van
On 10/12/2014 10:30 AM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:37:27PM -0400, r...@redhat.com wrote:
+static void init_numa_topology_type(void)
+{
+ int a, b, c, n;
+
+ n = sched_domains_numa_levels;
+
+ if (n <= 1)
+ sched_numa_topology_type = NUMA_DIRE
On 10/12/2014 09:17 AM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:37:26PM -0400, r...@redhat.com wrote:
+ sched_domains_numa_hops = kzalloc(sizeof(int) * nr_node_ids *
nr_node_ids, GFP_KERNEL);
+ if (!sched_domains_numa_hops)
+ return;
That's potentially a _BI
This can keep NUMA groups from converging.
Examining all nodes, when dealing with a task in a pseudo-interleaved
NUMA group, avoids this problem. Note that only CPUs in nodes that
improve the task or group score are examined, so the loop isn't too
bad.
Tested-by: Vinod Chegu
Signed-off-b
On 10/08/2014 02:43 AM, Yasuaki Ishimatsu wrote:
> The divide error is rare case because the trigger is node offline.
> By this patch, when both of private and shared are set to 0, diff
> is just set to 0, not calculating the division.
How about a simple
if (private + shared) == 0)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/2014 10:46 AM, Peter Zijlstra wrote:
> On Fri, Oct 03, 2014 at 10:28:42AM -0400, Rik van Riel wrote:
>> The current code has the potential to be quite painful on systems
>> with a large number of cores per chip, so we will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/2014 03:50 AM, Peter Zijlstra wrote:
> On Fri, Oct 03, 2014 at 08:23:04AM +0200, Mike Galbraith wrote:
>> On Thu, 2014-10-02 at 13:15 -0400, Rik van Riel wrote:
>>
>>> Subject: sched,idle: teach select_idle_sibli
Commit-ID: 347abad981c1ef815ea5ba861adba6a8c6aa1580
Gitweb: http://git.kernel.org/tip/347abad981c1ef815ea5ba861adba6a8c6aa1580
Author: Rik van Riel
AuthorDate: Tue, 30 Sep 2014 15:59:47 -0400
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 05:46:55 +0200
sched, time: Fix build
On 10/02/2014 03:26 PM, Linus Torvalds wrote:
> On Thu, Oct 2, 2014 at 12:07 PM, Kirill A. Shutemov
> wrote:
>>
>> I believe Sasha uses fakenuma in his KVM for that.
>
> Ok, so the benchmarks won't do anything then.
>
> I mean, I guess they might show some of the migration overhead, but
> they w
On Tue, 30 Sep 2014 19:15:00 -0400 (EDT)
Nicolas Pitre wrote:
> On Tue, 30 Sep 2014, Rik van Riel wrote:
> > The main thing it does not cover is already running tasks that
> > get woken up again, since select_idle_sibling() covers everything
> > except for newly forked and
On 10/02/2014 11:34 AM, Paul McQuade wrote:
> Use #include instead of
linux/mmu_context.h does not include asm/mmu_context.h
This leads me to believe that either fremap.c does not use
any definitions from either mmu_context.h file, or after
your change the code that fremap.c needs is no longer
gt; will not be triggered which is marginal in comparison to the complexity
> in dealing with the corner cases during THP split.
>
> Signed-off-by: Mel Gorman
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
userspace for now") but it should still skip VMAs the
> same way task_numa_work does.
>
> Signed-off-by: Mel Gorman
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
> double checking the VMA permissions when migration completes.
>
> Signed-off-by: Mel Gorman
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 10/01/2014 04:20 PM, Linus Torvalds wrote:
> Now, I'll be honest: this patch *migth* just work, but I expect it to
> have some stupid problem. It compiles. I haven't even dared boot it,
> much less try any numa benchmarks that woudln't show anything sane on
> my machine anyway.
>
> So I'm real
On 10/01/2014 12:18 PM, Linus Torvalds wrote:
> Seriously, why can't we just do this, and throw away all the crap that
> is "numa special case". This would make all the random games in
> change_pte_range() just go away entirely, because the whole NUMA thing
> really wouldn't be a special case for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/04/2014 11:32 AM, Nicolas Pitre wrote:
> The code in find_idlest_cpu() looks for the CPU with the smallest
> load. However, if multiple CPUs are idle, the first idle CPU is
> selected irrespective of the depth of its idle state.
>
> Among the id
llow a 32 bit system
with CONFIG_VIRT_CPU_ACCOUNTING_GEN enabled to build.
Make sure the correct cmpxchg function is used when doing
an atomic swap of a cputime_t.
Signed-off-by: Rik van Riel
Reported-by: Arnd Bergmann
---
arch/powerpc/include/asm/cputime.h| 2 ++
arch/s390/include/asm/
1201 - 1300 of 3700 matches
Mail list logo
