Am 29.11.2012 23:53, schrieb Kay Sievers:
> On Thu, Nov 29, 2012 at 11:46 PM, Joe Perches wrote:
>
>> It's still a scheduling issue with Kay and Jan's patches.
>> Does anyone have any idea if/when those patches are going in?
>
> I was expecting that Jan rebases the patches incorporating
> the la
Am 02.11.2012 04:53, schrieb Kay Sievers:
> On Mon, Oct 8, 2012 at 9:56 PM, Kay Sievers wrote:
>> On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
>
>>>> Jan,
>>>> any updates, did you try something else?
>>>> Or should we merge the
From: Jan H. Schönherr
The meaning of LOG_CONT is unclear, i. e., whether a message is a starting,
ending, or middle fragment. Unfortunately, this cannot be inferred from
the LOG_PREFIX and LOG_NEWLINE flags, as they are not always kept.
Furthermore, in some cases LOG_CONT is set, although it is
Hi Paul.
Am 23.08.2012 16:14, schrieb p...@google.com:
> Please find attached the latest version for CFS load-tracking.
Originally, I thought, this series also takes care of
the leaf-cfs-runqueue ordering issue described here:
http://lkml.org/lkml/2011/7/18/86
Now, that I had a closer look, I s
Am 23.08.2012 16:14, schrieb p...@google.com:
> From: Paul Turner
>
> Now that the machinery in place is in place to compute contributed load in a
> bottom up fashion; replace the shares distribution code within update_shares()
> accordingly.
[snip]
> static int update_shares_cpu(struct task_g
Am 23.08.2012 16:14, schrieb p...@google.com:
> From: Paul Turner
>
> Now that our measurement intervals are small (~1ms) we can amortize the
> posting
> of update_shares() to be about each period overflow. This is a large cost
> saving for frequently switching tasks.
[snip]
> @@ -1181,6 +118
From: Jan H. Schönherr
The meaning of LOG_CONT is unclear, i. e., whether a message is a starting,
ending, or middle fragment. Unfortunately, this cannot be inferred from
the LOG_PREFIX and LOG_NEWLINE flags, as they are not always kept.
Furthermore, in some cases LOG_CONT is set, although it is
Am 08.10.2012 21:24, schrieb Kay Sievers:
> On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
>> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
>
>>> Given that I'm able to fix the racing case, would you be in favor of
>>> this approa
Jan
[1] Joe Perches' printk reorganization: http://lkml.org/lkml/2012/10/24/748
[2] first version of patch 1: http://lkml.org/lkml/2012/9/26/392
[3] v1 of this series: http://lkml.org/lkml/2012/11/13/678
Jan H. Schönherr (14):
printk: drop ambiguous LOG_CONT flag
printk: use saved
continued by the next fragment.
(Unfortunately, we still have to look at the previous fragment to catch the
case of an unset LOG_PREFIX on this fragment, but a set LOG_NEWLINE on
the previous fragment -- and vice versa)
Tested-by: Kay Sievers
Signed-off-by: Jan H. Schönherr
---
v2:
- minor
If a message has been buffered, always use the saved timestamp reflecting
the actual occurrence of the message. (There is no reason to use a
possibly later timestamp.)
Signed-off-by: Jan H. Schönherr
---
This is a rather small change that could be folded into the next patch
which changes
. This commit restructures the logic to achieve that.
(Note, that LOG_NOCONS must still be set for partly _and_ fully printed
messages, making it a bit more complicated than just changing the
if-condition.)
Signed-off-by: Jan H. Schönherr
---
v2:
- fixed a bug, where the buffer was considered fully
-by: Jan H. Schönherr
---
added in v2
---
kernel/printk.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 13af61c..f6a91ec 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1392,15 +1392,13 @@ static struct cont
ushed"), then we can reuse it immediately instead of returning false.
Signed-off-by: Jan H. Schönherr
---
kernel/printk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index f6a91ec..7328348 100644
--- a/kernel/printk.c
+++ b/kerne
The checked criterion is loop-independent and we hold the lock necessary
to do the check also outside the loop. So, move that piece of code more
towards the end where the result is used.
Signed-off-by: Jan H. Schönherr
---
kernel/printk.c | 8
1 file changed, 4 insertions(+), 4
continuation buffer is not
checked again, but left until another call to console_unlock().
Signed-off-by: Jan H. Schönherr
---
This is not yet the final state I envision for this function, but it is
a working middle step. That is, the loop in console_cont_flush() is
rather ugly, and
done in follow-up patches.)
Signed-off-by: Jan H. Schönherr
---
v2:
- rephrased commit message to better reflect what the patch is doing
---
kernel/printk.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index
, this will also allow us to remove the tracking of the previous
message flags throughout the syslog/kmsg formatting code.
Signed-off-by: Jan H. Schönherr
---
v2:
- Fixed a bug that could mismerge continuation records, because
log_store() used "current" as the owner of the message passed i
] ()
(A-lines are printed with a single printk(), C-lines are printed
char-wise with KERN_CONT.)
Signed-off-by: Jan H. Schönherr
---
This definitely causes a notable change in the output that might go
beyond fixing the current output, depending on one&#
buffer overflowed before the next
message in sequence was retrieved, the output might end up with a
missing newline and/or header or an additional newline. OTOH, the
current code just silently ignores skipped messages...)
Signed-off-by: Jan H. Schönherr
---
v2:
- refactored patches
---
kernel
differs generally from the
order in which the message are stored. Therefore, it still keeps track
of the previously printed message.
Signed-off-by: Jan H. Schönherr
---
This could be folded into the previous patch.
---
kernel/printk.c | 59
laimable, thus, we still end up with alternating fragments in
syslog. I considered to add a delay before the cont buffer is flushed,
but it did not seem worth the effort.)
Signed-off-by: Jan H. Schönherr
---
new in v2
We still need a timer, but for a different purpose: Currently the
contents of
version print_text() that can also be used with
the continuation buffer and has the ability to start at a specific
position within the message and to track that position.
Signed-off-by: Jan H. Schönherr
---
v2:
- moved an already needed check from a later patch to this patch
- fixed a bug, where a
Am 07.12.2012 03:51, schrieb Joe Perches:
> On Thu, 2012-12-06 at 16:19 -0800, Andrew Morton wrote:
>> On Thu, 06 Dec 2012 15:37:30 -0800
>> Joe Perches wrote:
>>> Can you please pick this up for -next now and I'll
>>> redo my patches against -next for -rc1 so I'm not
>>> delayed until 3.9?
>>
>>
historical growth (patch 12) that only makes sense when
you have actually read the history.
Regards
Jan
[1] http://lkml.org/lkml/2012/10/24/748
[2] http://lkml.org/lkml/2012/9/26/392
Jan H. Schönherr (12):
printk: drop ambiguous LOG_CONT flag
printk: use saved timestamp for temporaril
continued by the next fragment.
(Unfortunately, we still have to look at the previous fragment to catch the
case of an unset LOG_PREFIX on this fragment, but a set LOG_NEWLINE on
the previous fragment.)
Tested-by: Kay Sievers
Signed-off-by: Jan H. Schönherr
---
Changes since last posting
If a message has been buffered, always use the saved timestamp reflecting
the actual occurrence of the message. (There is no reason to use a
possibly later timestamp.)
Signed-off-by: Jan H. Schönherr
---
This is a rather small change that could be folded into the next patch
which changes
. This commit restructures the logic to achieve that.
(Note, that LOG_NOCONS must still be set for partly _and_ fully printed
messages, making it a bit more complicated than just changing the
if-condition.)
Signed-off-by: Jan H. Schönherr
---
kernel/printk.c | 36
ushed"), then we can reuse it immediately instead of returning false.
Signed-off-by: Jan H. Schönherr
---
kernel/printk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index ba9494b..42e5eaf 100644
--- a/kernel/printk.c
+++ b/kerne
The checked criterion is loop-independent and we hold the lock necessary
to do the check also outside the loop. So, move that piece of code more
towards the end where the result is used.
Signed-off-by: Jan H. Schönherr
---
kernel/printk.c | 8
1 file changed, 4 insertions(+), 4
Many fields of struct cont are similar to those in struct log.
Reorganize struct cont and embed a struct log in it. This allows us
to use regular struct log functions also for continuation records,
without having to create a copy first.
Signed-off-by: Jan H. Schönherr
---
This is a prerequisite
version msg_print_text_from() with the ability to
start at a specific position within the message and to track the
position.
Signed-off-by: Jan H. Schönherr
---
kernel/printk.c | 54 --
1 file changed, 28 insertions(+), 26 deletions(-)
diff
console_unlock().
Signed-off-by: Jan H. Schönherr
---
This is not yet the final state I envision for this function, but it is
a working middle step. That is, the loop in console_cont_flush() is
rather ugly, and call_console_drivers() is still called from two places
with the same code around. This
] ()
(A-lines are printed with a single printk(), C-lines are printed
char-wise with KERN_CONT.)
Signed-off-by: Jan H. Schönherr
---
This definitely causes a notable change in the output that might go
beyond fixing the current output, depending on one&#
Retain a value of -1 for messages with an unknown message level and pass
this to log_store(). This way, we can later distinguish continuation
records from non-continuation records in log_store().
Signed-off-by: Jan H. Schönherr
---
kernel/printk.c | 28 +---
1 file
wline. OTOH, the
current code just silently ignores skipped messages...)
Signed-off-by: Jan H. Schönherr
---
kernel/printk.c | 60 +
1 file changed, 43 insertions(+), 17 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 6d
differs generally from the
order in which the message are stored. Therefore, it still keeps track
of the previously printed message.
Signed-off-by: Jan H. Schönherr
---
This could be folded into the previous patch.
---
kernel/printk.c | 54
Hi Greg.
This still needs a small fix, see below.
Am 03.11.2012 22:12, schrieb Jan H. Schönherr:
> From: Jan H. Schönherr
>
> The meaning of LOG_CONT is unclear, i. e., whether a message is a starting,
> ending, or middle fragment. Unfortunately, this cannot be inferred from
>
Am 15.11.2012 17:05, schrieb Kay Sievers:
> This with all your patches applied:
> [1.032804] input: ImExPS/2 Generic Explorer Mouse as
> /devices/platform/i8042/serio1/input/input2
> [1.063915] List of all partitions:
> [1.065521] 0800 117220824 sda driver: sd
> [1.067444]
Am 26.09.2012 23:15, schrieb Greg Kroah-Hartman:
> On Wed, Sep 26, 2012 at 07:58:45PM +0200, Jan H. Schönherr wrote:
>> Against v3.6-rc7, only lightly tested.
>
> Well, against linux-next and highly tested would be best. It's a bit
> late to get this into linux-next for 3
Am 27.09.2012 15:39, schrieb Kay Sievers:
> On Thu, Sep 27, 2012 at 12:33 AM, "Jan H. Schönherr"
> wrote:
>> "Tested" as in: it fixes my use case: multiple printk()s shortly after each
>> other -- with KERN_prefix but without a newline at the end. Those wer
Am 27.09.2012 17:46, schrieb "Jan H. Schönherr":
> If we say "if LOG_CONT is set, this message continues the previous one",
> we can also say "there is no prefix on this message". Then on the other
> hand, we would need a "whatever comes next, it does
Am 27.09.2012 18:04, schrieb Jan H. Schönherr:
> Am 27.09.2012 17:46, schrieb Jan H. Schönherr:
>> If we say "if LOG_CONT is set, this message continues the previous one",
>> we can also say "there is no prefix on this message". Then on the other
>> hand,
Am 28.09.2012 16:34, schrieb Kay Sievers:
> On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
> That fails the racing task test, and a cont user that was nicely
> merged before is now all in separate records.
I guess, I need to extend my test cases. Do you have something
ready that I
s not specified, the memory is removed from the e820 map.
Signed-off-by: Jan H. Schönherr
---
Documentation/admin-guide/kernel-parameters.txt | 9 +
arch/x86/kernel/e820.c | 18 ++
2 files changed, 27 insertions(+)
diff --git a/Documentatio
("mm: fix mixed zone detection in devm_memremap_pages")
Signed-off-by: Jan H. Schönherr
---
kernel/memremap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 403ab9c..4712ce6 100644
--- a/kernel/memremap.c
+++ b/kernel/
additional argument to
indicate where to stop, so that only newly added entries are removed
from the tree.
Fixes: 9476df7d80df ("mm: introduce find_dev_pagemap()")
Signed-off-by: Jan H. Schönherr
---
kernel/memremap.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
di
On 23/11/2018 17.51, Frederic Weisbecker wrote:
> On Tue, Sep 18, 2018 at 03:22:13PM +0200, Jan H. Schönherr wrote:
>> On 09/17/2018 11:48 AM, Peter Zijlstra wrote:
>>> Right, so the whole bandwidth thing becomes a pain; the simplest
>>> solution is to detect the
On 19/10/2018 02.26, Subhra Mazumdar wrote:
> Hi Jan,
Hi. Sorry for the delay.
> On 9/7/18 2:39 PM, Jan H. Schönherr wrote:
>> The collective context switch from one coscheduled set of tasks to another
>> -- while fast -- is not atomic. If a use-case needs the absolute gua
On 27/10/2018 01.05, Subhra Mazumdar wrote:
>
>
>> D) What can I *not* do with this?
>> -
>>
>> Besides the missing load-balancing within coscheduled task-groups, this
>> implementation has the following properties, which might be considered
>> short-comings.
>>
>>
On 17/10/2018 04.09, Frederic Weisbecker wrote:
> On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Schönherr wrote:
>> C) How does it work?
>>
[...]
>> For each task-group, the user can select at which level it should be
>> scheduled. If yo
On 19/10/2018 17.45, Rik van Riel wrote:
> On Fri, 2018-10-19 at 17:33 +0200, Frederic Weisbecker wrote:
>> On Fri, Oct 19, 2018 at 11:16:49AM -0400, Rik van Riel wrote:
>>> On Fri, 2018-10-19 at 13:40 +0200, Jan H. Schönherr wrote:
>>>>
>>>> Now, it
On 09/18/2018 02:33 AM, Subhra Mazumdar wrote:
> On 09/07/2018 02:39 PM, Jan H. Schönherr wrote:
>> A) Quickstart guide for the impatient.
>> --
>>
>> Here is a quickstart guide to set up coscheduling at core-level for
>> select
On 09/17/2018 11:48 AM, Peter Zijlstra wrote:
> On Sat, Sep 15, 2018 at 10:48:20AM +0200, Jan H. Schönherr wrote:
>> On 09/14/2018 06:25 PM, Jan H. Schönherr wrote:
>
>>> b) ability to move CFS RQs between CPUs: someone changed the affinity of
>>>a cpuset? No pro
On 09/18/2018 03:38 PM, Peter Zijlstra wrote:
> On Tue, Sep 18, 2018 at 03:22:13PM +0200, Jan H. Schönherr wrote:
>> AFAIK, changing the affinity of a cpuset overwrites the individual
>> affinities of tasks
>> within them. Thus, it shouldn't be an issue.
>
> N
On 05/29/2015 09:47 AM, Len Brown wrote:
However, a clear pattern jumped out of the trace for how long
the BSP waits for the AP to set itself in cpu_callin_mask.
This is the time in start secondary where cpu_init() is running,
up through smp_callin() is called.
On the 1st package, each remote AP
From: Jan H. Schönherr
There is a race condition in SMP bootup code, which may result in
WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
workqueue_cpu_up_callback()
or
kernel BUG at kernel/smpboot.c:135!
It can be triggered with a bit of luck in Linux guests running on
busy hosts
From: Jan H. Schönherr
There is a race condition in SMP bootup code, which may result in
WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
workqueue_cpu_up_callback()
or
kernel BUG at kernel/smpboot.c:135!
It can be triggered with a bit of luck in Linux guests running on
busy hosts
From: Jan H. Schönherr
There is a race condition in SMP bootup code, which may result in
WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
workqueue_cpu_up_callback()
or
kernel BUG at kernel/smpboot.c:135!
It can be triggered with a bit of luck in Linux guests running on
busy hosts
On 05/14/2015 09:18 AM, Len Brown wrote:
On Thu, May 14, 2015 at 2:36 AM, Len Brown wrote:
[2.737884] x86: Booted up 4 nodes, 120 CPUs
For the record, the same (bare metal) box running latest tip boots
10ms/processor quicker
[1.553658] x86: Booted up 4 nodes, 120 CPUs
BTW. thi
ved as part of
c/s 23724 by Tim Deegan).
Signed-off-by: Gang Wei
Acked-by: Keir Fraser
Acked-by: Tim Deegan
Committed-by: Tim Deegan
Signed-off-by: Jan H. Schönherr
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Tim Deegan
Cc: Gang Wei
---
arch/x86/kernel/
very first reads.
Signed-off-by: Jan H. Schönherr
---
v2:
- Dropped the other hacky patch for the time being.
- Fixed the early exit check.
- Hopefully fixed all inaccurate math in v1.
- Extended comments.
arch/x86/kernel/tsc.c | 91 +++
1 file changed, 57
Am 12.02.19 um 12:57 schrieb Thomas Gleixner:
On Tue, 29 Jan 2019, Thomas Gleixner wrote:
On Tue, 29 Jan 2019, Jan H. Schönherr wrote:
Am 29.01.2019 um 11:23 schrieb Jan H. Schönherr:
+calibrate:
+ /*
+* Extrapolate the error and fail fast if the error will
+* never be
Am 14.02.19 um 22:46 schrieb Jan H. Schönherr:
Some systems experience regular interruptions (60 Hz SMI?), that prevent
the quick PIT calibration from succeeding: individual interruptions can be
so long, that the PIT MSB is observed to decrement by 2 or 3 instead of 1.
The existing code cannot
PU16 in my case) hasn't been resumed yet. (I did some experiments
with CPU hotplug before and after suspend, but apart from reproducing
the issue and verifying the "fix", I got nowhere.)
The patches are against v4.20.
Jan H. Schönherr (2):
x86/tsc: Allow quick PIT calibration de
Fatal1ty X399 Professional Gaming, BIOS P3.30.
This unexplained behavior goes away as soon as the sibling CPU of the
boot CPU is brought back up. Hence, add a hack to restore the sibling
CPU before all others on unfreeze. This keeps the TSC stable.
Signed-off-by: Jan H. Schönherr
---
kernel/cpu.c
very first reads.
Signed-off-by: Jan H. Schönherr
---
arch/x86/kernel/tsc.c | 80 +--
1 file changed, 46 insertions(+), 34 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index e9f777bfed40..a005e0aa215e 100644
--- a/arch/x86/kernel
Hi Suravee.
I wonder, how this interacts with Hyper-V SynIC; see comments below.
On 22/03/2019 12.57, Suthikulpanit, Suravee wrote:
> AMD AVIC does not support ExtINT. Therefore, AVIC must be temporary
> deactivated and fall back to using legacy interrupt injection via
> vINTR and interrupt windo
On 22/03/2019 12.57, Suthikulpanit, Suravee wrote:
> Activate/deactivate AVIC requires setting/unsetting the memory region used
> for APIC_ACCESS_PAGE_PRIVATE_MEMSLOT. So, re-factor avic_init_access_page()
> to avic_setup_access_page() and add srcu_read_lock/unlock, which are needed
> to allow this
On 22/03/2019 12.57, Suthikulpanit, Suravee wrote:
> When activate / deactivate AVIC during runtime, all vcpus has to be
> operating in the same mode. So, introduce new interface to request
> all vCPUs to activate/deactivate APICV.
If we need to switch APICV on and off on all vCPUs of a VM, should
On 22/03/2019 12.57, Suthikulpanit, Suravee wrote:
> Introduce a helper function for setting lapic parameters when
> activate/deactivate apicv.
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/kvm/lapic.c | 23 ++-
> arch/x86/kvm/lapic.h | 1 +
> 2 files changed, 19
On 09/12/2018 02:24 AM, Nishanth Aravamudan wrote:
> [ I am not subscribed to LKML, please keep me CC'd on replies ]
>
> I tried a simple test with several VMs (in my initial test, I have 48
> idle 1-cpu 512-mb VMs and 2 idle 2-cpu, 2-gb VMs) using libvirt, none
> pinned to any CPUs. When I tried
On 09/12/2018 09:34 PM, Jan H. Schönherr wrote:
> That said, I see a hang, too. It seems to happen, when there is a
> cpu.scheduled!=0 group that is not a direct child of the root task group.
> You seem to have "/sys/fs/cgroup/cpu/machine" as an intermediate group.
> (T
On 09/13/2018 01:15 AM, Nishanth Aravamudan wrote:
> [...] if I just try to set machine's
> cpu.scheduled to 1, with no other changes (not even changing any child
> cgroup's cpu.scheduled yet), I get the following trace:
>
> [16052.164259] [ cut here ]
> [16052.168973] rq->
Partly-reported-by: Nishanth Aravamudan
Signed-off-by: Jan H. Schönherr
---
kernel/sched/cosched.c | 2 ++
kernel/sched/fair.c| 35 ++-
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/kernel/sched/cosched.c b/kernel/sched/cosched.c
index a1f0d3
On 09/14/2018 01:12 PM, Peter Zijlstra wrote:
> On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Schönherr wrote:
>> This patch series extends CFS with support for coscheduling. The
>> implementation is versatile enough to cover many different coscheduling
>> use-cases, w
On 09/14/2018 06:25 PM, Jan H. Schönherr wrote:
> On 09/14/2018 01:12 PM, Peter Zijlstra wrote:
>>
>> There are known scalability problems with the existing cgroup muck; you
>> just made things a ton worse. The existing cgroup overhead is
>> significant, you also
On 09/18/2018 04:40 PM, Rik van Riel wrote:
> On Fri, 2018-09-14 at 18:25 +0200, Jan H. Schönherr wrote:
>> On 09/14/2018 01:12 PM, Peter Zijlstra wrote:
>>> On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Schönherr wrote:
>>>>
>>>> B) Why would I want t
On 09/19/2018 11:53 PM, Subhra Mazumdar wrote:
> Can we have a more generic interface, like specifying a set of task ids
> to be co-scheduled with a particular level rather than tying this with
> cgroups? KVMs may not always run with cgroups and there might be other
> use cases where we might want
On 09/17/2018 03:37 PM, Peter Zijlstra wrote:
> On Fri, Sep 14, 2018 at 06:25:44PM +0200, Jan H. Schönherr wrote:
>> With gang scheduling as defined by Feitelson and Rudolph [6], you'd have to
>> explicitly schedule idle time. With coscheduling as defined by Ousterhout
>
On 09/17/2018 02:25 PM, Peter Zijlstra wrote:
> On Fri, Sep 14, 2018 at 06:25:44PM +0200, Jan H. Schönherr wrote:
>
>> Assuming, there is a cgroup-less solution that can prevent simultaneous
>> execution of tasks on a core, when they're not supposed to. How would you
>&
On 09/26/2018 11:05 PM, Nishanth Aravamudan wrote:
> On 26.09.2018 [10:25:19 -0700], Nishanth Aravamudan wrote:
>>
>> I found another issue today, while attempting to test (with 61/60
>> applied) separate coscheduling cgroups for vcpus and emulator threads
>> [the default configuration with libvirt
On 09/18/2018 04:35 PM, Rik van Riel wrote:
> On Tue, 2018-09-18 at 15:22 +0200, Jan H. Schönherr wrote:
[...]
> Task priorities in a flat runqueue are relatively straightforward, with
> vruntime scaling just like done for nice levels, but I have to admit
> that throttled grou
Factor out the logic to place a SE into a CFS runqueue into its own
function.
This consolidates various sprinkled updates of se->cfs_rq, se->parent,
and se->depth at the cost of updating se->depth unnecessarily on
same-group movements between CPUs.
Signed-off-by: Jan H. Schönherr
Just like init_tg_cfs_entry() does something useful without a scheduling
entity, let it do something useful without a CFS runqueue.
This prepares for the addition of new types of SEs.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/fair.c | 28 +++-
1 file changed, 15
sched_domain_topology
is replaced with another one.
Signed-off-by: Jan H. Schönherr
---
include/linux/sched/topology.h | 1 +
kernel/sched/topology.c| 5 +
2 files changed, 6 insertions(+)
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index
to what NUMA already does on top of the system topology).
Signed-off-by: Jan H. Schönherr
---
include/linux/sched/topology.h | 11 ---
kernel/sched/topology.c| 40 ++--
2 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/include
There is fair amount of overlap between enqueue_task_fair() and
unthrottle_cfs_rq(), as well as between dequeue_task_fair() and
throttle_cfs_rq(). This is the first step toward having both of
them use the same basic function.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/fair.c | 82
Make the task delta handled by enqueue_entity_fair() and dequeue_task_fair()
variable as required by unthrottle_cfs_rq() and throttle_cfs_rq().
Signed-off-by: Jan H. Schönherr
---
kernel/sched/fair.c | 18 ++
kernel/sched/sched.h | 6 --
2 files changed, 14 insertions
Add entity variants of put_prev_task_fair() and set_curr_task_fair()
that will be later used by coscheduling.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/fair.c | 34 +-
kernel/sched/sched.h | 2 ++
2 files changed, 23 insertions(+), 13 deletions(-)
diff
Locks within the runqueue hierarchy are always taken from bottom to top
to avoid deadlocks. Let the lock validator know about this by declaring
different runqueue levels as distinct lock classes.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/sched.h | 29 ++---
1 file
rithm operating on the NUMA distance matrix.
Also, as mentioned before, not everyone needs the finer granularity.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/core.c| 1 +
kernel/sched/cosched.c | 259 +
kernel/sched/sched.h | 2 +
3
from disabling
NOHZ and allows us to gradually improve the situation later.
Signed-off-by: Jan H. Schönherr
---
kernel/time/tick-sched.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 5b33e2f5c0ed..5e9c2a7d4ea9 100644
Modify update_blocked_averages() and update_cfs_rq_h_load() so that they
won't access the next higher hierarchy level, for which they don't hold a
lock.
This will have to be touched again, when load balancing is made
functional.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/
queue. This is used during load balancing. We keep these lists per
hierarchy level, which corresponds to the lock we hold and also
keeps the per-CPU logic compatible to what is there.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/fair.c | 12 ++--
1 file changed, 6 insertions(+), 6 dele
.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/core.c| 2 ++
kernel/sched/cosched.c | 19 +++
kernel/sched/sched.h | 4
3 files changed, 25 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a9f5339d58cb..b3ff885a88d4 100644
--- a/kernel/sched
beyond that of the
root task group. The value for the root task group cannot be configured
via this interface. It has to be configured with a command line
argument, which will be added later.
The function sdrq_update_root() will be filled in a follow-up commit.
Signed-off-by: Jan H. Schönherr
Jan H. Schönherr
---
kernel/sched/fair.c | 107 +---
1 file changed, 102 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 483db54ee20a..bc219c9c3097 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fai
actual decisions on the (SD-)SE, under which there were no
tasks.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/core.c | 11 +++
kernel/sched/fair.c | 43 +---
kernel/sched/idle.c | 7 ++-
kernel/sched/sched.h | 55
locked per-CPU
runqueue upwards, locking/unlocking runqueues as they go along, stopping
when they would leave their area of responsibility.
Signed-off-by: Jan H. Schönherr
---
kernel/sched/cosched.c | 94 ++
kernel/sched/sched.h | 11 ++
2
1 - 100 of 152 matches
Mail list logo
