r, each individual kworker
> > > can potentially have CPU share equal to the entire UX cgroup.
> > >
> > > -kworker/0:0
> > > -kworker/1:0
> > > - UX
> > > Task-A
> > > Task-B
> > > - background
> > > Task-X
>
. This helps in prioritizing
> > Task-A and Task-B over Task-X and Task-Y. However, each individual kworker
> > can potentially have CPU share equal to the entire UX cgroup.
> >
> > -kworker/0:0
> > -kworker/1:0
> > - UX
> > Task-A
> > Task-B
>
d Task-Y. However, each individual kworker
> can potentially have CPU share equal to the entire UX cgroup.
>
> -kworker/0:0
> -kworker/1:0
> - UX
> Task-A
> Task-B
> - background
> Task-X
> Task-Y
> Hence we want to move all kernel threads to a
> > are mounted on different hierarchies.
> >
> > We also see kthreadd_task and any kernel thread created after the Android
> > boot
> > also stuck in the root cgroup. The current code prevents kthreadd_task
> > moving
> > out root cgroup to avoid the po
root cgroup. The current code prevents kthreadd_task moving
> out root cgroup to avoid the possibility of creating new RT kernel threads
> inside a cgroup with no RT runtime allocated. Apply this restriction when
> tasks
> are moving out of cpu cgroup under CONFIG_RT_GROUP_SCHED. Thi
s
are mounted on different hierarchies.
We also see kthreadd_task and any kernel thread created after the Android boot
also stuck in the root cgroup. The current code prevents kthreadd_task moving
out root cgroup to avoid the possibility of creating new RT kernel threads
inside a cgroup with no RT ru
see kthreadd_task and any kernel thread created after the Android
> > boot
> > also stuck in the root cgroup. The current code prevents kthreadd_task
> > moving
> > out root cgroup to avoid the possibility of creating new RT kernel threads
> > inside a cgroup with n
t cgroup to avoid the possibility of creating new RT kernel threads
> inside a cgroup with no RT runtime allocated. Apply this restriction when
> tasks
> are moving out of cpu cgroup under CONFIG_RT_GROUP_SCHED. This allows all
> kernel threads to be moved out of root cpu cgroup if the ker
ernel thread created after the Android boot
also stuck in the root cgroup. The current code prevents kthreadd_task moving
out root cgroup to avoid the possibility of creating new RT kernel threads
inside a cgroup with no RT runtime allocated. Apply this restriction when tasks
are moving out of cpu c
On Wed, Mar 17, 2021 at 11:12:41AM -0700, Andy Lutomirski wrote:
> @@ -163,6 +163,19 @@ int copy_thread(unsigned long clone_flags, unsigned long
> sp, unsigned long arg,
> /* Kernel thread ? */
> if (unlikely(p->flags & PF_KTHREAD)) {
> memset(childregs, 0, sizeof(struct
For kernel threads, task_pt_regs is currently all zeros, a valid user state
(if kernel_execve() has been called), or some combination thereof during
execution of kernel_execve(). If a stack trace is printed, the unwinder
might get confused and treat task_pt_regs as a kernel state. Indeed
s a kernel thread in order
to assume that kernel threads are privileged for socket operations was
(current->flags & PF_KTHREAD). Now that uaccess_kernel() became 0 on x86,
tomoyo has to fix this problem. Do like commit 942cb357ae7d9249 ("Smack:
Handle io_uring kernel thread privileges&
to assume that kernel threads are privileged for socket operations was
(current->flags & PF_KTHREAD). Now that uaccess_kernel() became 0 on x86,
tomoyo has to fix this problem. Do like commit 942cb357ae7d9249 ("Smack:
Handle io_uring kernel thread privileges") does.
Signed-off-by:
On Thu, Mar 04, 2021 at 11:05:57AM -0800, Andy Lutomirski wrote:
> For kernel threads, task_pt_regs is currently all zeros, a valid user state
> (if kernel_execve() has been called), or some combination thereof during
> execution of kernel_execve(). If a stack trace is printed, the
For kernel threads, task_pt_regs is currently all zeros, a valid user state
(if kernel_execve() has been called), or some combination thereof during
execution of kernel_execve(). If a stack trace is printed, the unwinder
might get confused and treat task_pt_regs as a kernel state. Indeed
When a kernel thread performs memory access on behalf of a process (like
in async I/O, io_uring, etc.) it has to respect tagging setup of the
process as user addresses can include tags.
Normally, LAM setup is per-thread and recorded in thread flags, but for
this use case we also track LAM setup pe
To synthesize information to resolve sample IPs, it needs to scan task
and mmap info from the /proc filesystem. For each process, it
opens (and reads) status and maps file respectively. But as kernel
threads don't have memory maps so we can skip the maps file.
To find kernel threads,
> and mmap info from the /proc filesystem. For each process, it
> > > opens (and reads) status and maps file respectively. But as kernel
> > > threads don't have memory maps so we can skip the maps file.
> > >
> > > To find kernel threads, check "VmPea
d reads) status and maps file respectively. But as kernel
> > threads don't have memory maps so we can skip the maps file.
> >
> > To find kernel threads, check "VmPeak:" line in /proc//status
> > file. It's about the peak virtual memory usage so only user-l
On Fri, Jan 29, 2021 at 02:49:00PM +0900, Namhyung Kim wrote:
> To synthesize information to resolve sample IPs, it needs to scan task
> and mmap info from the /proc filesystem. For each process, it
> opens (and reads) status and maps file respectively. But as kernel
> threads don&#
To synthesize information to resolve sample IPs, it needs to scan task
and mmap info from the /proc filesystem. For each process, it
opens (and reads) status and maps file respectively. But as kernel
threads don't have memory maps so we can skip the maps file.
To find kernel threads,
d reads) status and maps file respectively. But as kernel
> > threads don't have memory maps so we can skip the maps file.
> >
> > To find kernel threads, check "VmPeak:" line in /proc//status
> > file. It's about the peak virtual memory usage so onl
On Mon, Dec 21, 2020 at 04:00:28PM +0900, Namhyung Kim wrote:
> To synthesize information to resolve sample IPs, it needs to scan task
> and mmap info from the /proc filesystem. For each process, it
> opens (and reads) status and maps file respectively. But as kernel
> threads don&#
To synthesize information to resolve sample IPs, it needs to scan task
and mmap info from the /proc filesystem. For each process, it
opens (and reads) status and maps file respectively. But as kernel
threads don't have memory maps so we can skip the maps file.
To find kernel threads,
Committer: Peter Zijlstra
CommitterDate: Mon, 15 Jun 2020 14:10:03 +02:00
isolcpus: Affine unbound kernel threads to housekeeping cpus
This is a kernel enhancement that configures the cpu affinity of kernel
threads via kernel boot option nohz_full=.
When this option is specified, the cpumask is
From: Marcelo Tosatti
This is a kernel enhancement that configures the cpu affinity of kernel
threads via kernel boot option nohz_full=.
When this option is specified, the cpumask is immediately applied upon
kthread launch. This does not affect kernel threads that specify cpu
and node.
This
> > > On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote:
> > > > > When kernel threads are created for later use, they will be in
> > > > > TASK_UNINTERRUPTIBLE state until they are woken up. This results
> > > > > in increase
bind);
> > >
> > > It's as if people never read mailing lists:
> > >
> > > https://lore.kernel.org/r/dm6pr11mb3531d3b164357b2dc476102ddf...@dm6pr11mb3531.namprd11.prod.outlook.com
> > >
> > > Given that this is an identical resend of the
On Thu, May 21, 2020 at 07:05:44AM +0530, Pavan Kondeti wrote:
> On Wed, May 20, 2020 at 08:18:58PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote:
> > > When kernel threads are created for later us
On Wed, May 20, 2020 at 08:18:58PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote:
> > When kernel threads are created for later use, they will be in
> > TASK_UNINTERRUPTIBLE state until they are woken up. This results
> >
On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote:
> When kernel threads are created for later use, they will be in
> TASK_UNINTERRUPTIBLE state until they are woken up. This results
> in increased loadavg and false hung task reports. To fix this,
> use TASK_IDLE stat
When kernel threads are created for later use, they will be in
TASK_UNINTERRUPTIBLE state until they are woken up. This results
in increased loadavg and false hung task reports. To fix this,
use TASK_IDLE state instead of TASK_UNINTERRUPTIBLE when
a kernel thread schedules out for the first time
> From: Pavel Machek
> Sent: Tuesday, May 5, 2020 5:10 AM
> To: Greg Kroah-Hartman
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Dexuan Cui
> ; Rafael J. Wysocki
> Subject: Re: [PATCH 4.19 11/37] PM: hibernate: Freeze kernel threads in
> software_resume()
&
Hi!
> commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
>
> Currently the kernel threads are not frozen in software_resume(), so
> between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(),
> system_freezable_power_efficient_wq can still try to submit SCSI
>
From: Dexuan Cui
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so
between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(),
system_freezable_power_efficient_wq can still try to submit SCSI
commands and this
From: Dexuan Cui
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so
between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(),
system_freezable_power_efficient_wq can still try to submit SCSI
commands and this
From: Dexuan Cui
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so
between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(),
system_freezable_power_efficient_wq can still try to submit SCSI
commands and this
From: Dexuan Cui
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so
between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(),
system_freezable_power_efficient_wq can still try to submit SCSI
commands and this
From: Dexuan Cui
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so
between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(),
system_freezable_power_efficient_wq can still try to submit SCSI
commands and this
/Waiman-Long/sched-core-Don-t-use-dying-mm-as-active_mm-for-kernel-threads/20190728-101948
config: i386-allnoconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add
/Waiman-Long/sched-core-Don-t-use-dying-mm-as-active_mm-for-kernel-threads/20190728-101948
config: x86_64-randconfig-s1-07280001 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you
On 7/26/19 7:45 PM, Waiman Long wrote:
> It was found that a dying mm_struct where the owning task has exited can
> stay on as active_mm of kernel threads as long as no other user tasks
> run on those CPUs that use it as active_mm. This prolongs the life time
> of dying mm holding u
It was found that a dying mm_struct where the owning task has exited can
stay on as active_mm of kernel threads as long as no other user tasks
run on those CPUs that use it as active_mm. This prolongs the life time
of dying mm holding up memory and other resources that cannot be freed.
Fix that
PF_KTHREAD to check for kernel threads
!current->mm is not a reliable indicator for kernel threads as they might
temporarily use a user mm. Check for PF_KTHREAD instead.
Signed-off-by: Thomas Gleixner
Acked-by: Mark Rutland
Cc: Josh Poimboeuf
Cc: Peter Zijlstra
Cc: Steven Rostedt
Link:
ht
On Tue, Jul 02, 2019 at 05:53:35PM +0200, Thomas Gleixner wrote:
> !current->mm is not a reliable indicator for kernel threads as they might
> temporarily use a user mm. Check for PF_KTHREAD instead.
>
> Signed-off-by: Thomas Gleixner
FWIW:
Acked-by: Mark Rutland
As a head
!current->mm is not a reliable indicator for kernel threads as they might
temporarily use a user mm. Check for PF_KTHREAD instead.
Signed-off-by: Thomas Gleixner
---
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -228,7 +228,7 @@ unsigned int stack_trace_save_user(un
Prepare for cgroup aware workqueues by introducing cgroup_attach_kthread
and a helper cgroup_attach_kthread_to_dfl_root.
A workqueue worker will always migrate itself, so for now use @current
in the interfaces to avoid handling task references.
Signed-off-by: Daniel Jordan
---
include/linux/cgr
On 10/19/2018 10:37 AM, Andy Lutomirski wrote:
>> I think it's much more straightforward to just not enforce pkeys.
>> Having this "phantom" value could cause a very odd, nearly
>> undebuggable I/O failure.
> But now we have the reverse. The IO can work if it’s truly async but,
> if the kernel dec
> On Oct 19, 2018, at 10:01 AM, Dave Hansen wrote:
>
> On 10/19/2018 09:59 AM, Andy Lutomirski wrote:
>>> That looks like a good API in general. The ffs_user_copy_worker that
>>> Sebastian mentioned seems to be used by AIO, in which case of course it
>>> has to happen in a kernel thread.
>>>
On 10/19/2018 09:59 AM, Andy Lutomirski wrote:
>> That looks like a good API in general. The ffs_user_copy_worker that
>> Sebastian mentioned seems to be used by AIO, in which case of course it
>> has to happen in a kernel thread.
>>
>> But while the API is good, deciding on the desired semantics
> On Oct 19, 2018, at 12:44 AM, Paolo Bonzini wrote:
>
> On 18/10/2018 22:46, Andy Lutomirski wrote:
>>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker()
>>>
>>> Sebastian
>> I think we need an entirely new API:
>>
>> user_mm_ctx_t ctx = user_mm_ctx_get();
>>
>> ...
>>
>> use
On 18/10/2018 22:46, Andy Lutomirski wrote:
>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker()
>>
>> Sebastian
> I think we need an entirely new API:
>
> user_mm_ctx_t ctx = user_mm_ctx_get();
>
> ...
>
> use_user_mm_ctx(ctx);
> unuse_user_mm_ctx(ctx);
>
> ...
>
> user_mm_ctx_pu
gt;
>> Bypassing protection keys is not a big deal IMNHO. In places where a
>> sane one is not readily available, I'm totally fine with just
>> effectively disabling it (PKRU=0) for the length of time it isn't available.
>
> Okay, this makes things easier. Let docu
not readily available, I'm totally fine with just
> effectively disabling it (PKRU=0) for the length of time it isn't available.
Okay, this makes things easier. Let document that for kernel threads we
use PKRU=0. This should be happening in my try right now. I double check
tomorrow just in case…
Sebastian
On 10/18/2018 01:46 PM, Andy Lutomirski wrote:
> Setting it to allow-all/none would let the operation always fail or
> succeed which might be an improvement in terms of debugging. However it
> is hard to judge what the correct behaviour should be. Should fail or
> succeed.
Succeed. :)
> But this
On Thu, Oct 18, 2018 at 11:25 AM Sebastian Andrzej Siewior
wrote:
>
> On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote:
> > > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> > > wrote:
> > >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> > >> On Fri, Oct 12, 2018 at 10:5
On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote:
> > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> > wrote:
> >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> >> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
> >>> So I'm kinda missing the point of the patch.
> >>
> >>
On 10/18/2018 09:48 AM, Andy Lutomirski wrote:
>>>> We might want to do this for cleanliness reasons... Maybe.
>>>>
>>>> But this *should* have no practical effects. Kernel threads have no
>>>> real 'mm' and no user pages. They should
iewior wrote:
>>>> The PKRU value is not set for kernel threads because they do not have
>>>> the ->initialized value set. As a result the kernel thread has a random
>>>> PKRU value set which it inherits from the previous task.
>>>> It has been suggest
On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
> wrote:
> >
> > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > > The PKRU value is not set for kernel threads because they do not have
> > &g
On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The PKRU value is not set for kernel threads because they do not have
> > the ->initialized value set. As a result the kernel thread has a random
> &
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The PKRU value is not set for kernel threads because they do not have
> the ->initialized value set. As a result the kernel thread has a random
> PKRU value set which it inherits from the previous task.
> It has been sug
The PKRU value is not set for kernel threads because they do not have
the ->initialized value set. As a result the kernel thread has a random
PKRU value set which it inherits from the previous task.
It has been suggested by Paolo Bonzini to set it for kernel threads, too
because it might be a
On Thu, Dec 14, 2017 at 11:43 AM, Peter Zijlstra wrote:
> On Thu, Dec 14, 2017 at 12:27:32PM +0100, Peter Zijlstra wrote:
>> From: Thomas Gleixner
>>
>> Kernel threads can use the mm of a user process temporarily via use_mm(),
>> but there is no point in installing the
On Thu, Dec 14, 2017 at 12:27:32PM +0100, Peter Zijlstra wrote:
> From: Thomas Gleixner
>
> Kernel threads can use the mm of a user process temporarily via use_mm(),
> but there is no point in installing the LDT which is associated to that mm
> for the kernel thread.
So thinki
From: Thomas Gleixner
Kernel threads can use the mm of a user process temporarily via use_mm(),
but there is no point in installing the LDT which is associated to that mm
for the kernel thread.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/mmu_context.h |3 +--
1 file changed, 1
On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Kernel threads can use the mm of a user process temporarily via use_mm(),
> but there is no point in installing the LDT which is associated to that mm
> for the kernel thread.
>
I like this one.
From: Thomas Gleixner
Kernel threads can use the mm of a user process temporarily via use_mm(),
but there is no point in installing the LDT which is associated to that mm
for the kernel thread.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/mmu_context.h |3 +--
1 file changed, 1
On (06/30/17 14:11), Petr Mladek wrote:
> > 2) can offload printing to other CPUs from vprintk_emit()
> >and avoid any of scheduler->timekeeping->etc. paths. which will
> >replace printk_deferred().
>
> I probably miss something. There is still called wake_up_process()
> in this patchset a
On Thu 2017-06-29 16:56:30, Sergey Senozhatsky wrote:
> yeah, I agree and understand that per-CPU printk kthreads
> is a bit... too much.
>
> it was just a quick idea and I just gave it a try. but there
> are some potential takeaways from the series (not sure if you
> looked at the last patches of
On (06/28/17 15:42), Petr Mladek wrote:
[..]
> My head is whirling when thinking about all the per-CPU stuff. It is
> looking for escape. The way is to keep it as simple as possible.
>
> After all, we should need all this only when there is a flood of
> messages. Otherwise, the messages should be
On Thu 2017-06-08 17:18:29, Sergey Senozhatsky wrote:
> we still don't have guarantees that printk_kthread will be scheduled on
> a CPU that can run it immediately or anytime in the future, but not too
> late. printk_kthread can even be scheduled on the CPU that has requested
> offloading in the fi
From: Martin Schwidefsky
commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream.
Return a sensible value if TASK_SIZE if called from a kernel thread.
This gets us around an issue with copy_mount_options that does a magic
size calculation "TASK_SIZE - (unsigned long)data" while in a kernel
thr
Hello,
On (06/02/17 18:03), Sergey Senozhatsky wrote:
[..]
> I've managed to reproduce some of the issues with a single printk
> kthread solution that Jan Kara talked about. Sometimes scheduler decides
> sometimes scheduler decides that printk kthread should run on the same CPU
> as the proc
Hello,
RFC
This patch set adds a printk() SMP kernel threads which let us
to print kernel messages to the console from a non-atomic/schedule-able
context, avoiding different sort of lockups, stalls, etc.
A completely reworked version, for more details please
see 0003
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Martin Schwidefsky
commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream.
Return a sensible value if TASK_SIZE if called from a kernel thread.
This gets us around an issue with copy_mount_
From: Martin Schwidefsky
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream.
Return a sensible value if TASK_SIZE if called from a kernel thread.
This gets us around an issue with copy_mount_opt
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Martin Schwidefsky
commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream.
Return a sensible value if TASK_SIZE if called from a kernel thread.
This gets us around an issue with copy_mount_
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Martin Schwidefsky
commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream.
Return a sensible value if TASK_SIZE if called from a kernel thread.
This gets us around an issue with copy_mount_o
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Martin Schwidefsky
commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream.
Return a sensible value if TASK_SIZE if called from a kernel thread.
This gets us around an issue with copy_mount_o
On Sat, 25 Feb 2017 10:19:04 -0800
Linus Torvalds wrote:
> On Fri, Feb 24, 2017 at 8:15 AM, Martin Schwidefsky
> wrote:
> >
> > Now I fixed this in the s390 code, the patch is queued and will be
> > included in next weeks please-pull. But I am wondering about the use
&g
On Fri, Feb 24, 2017 at 8:15 AM, Martin Schwidefsky
wrote:
>
> Now I fixed this in the s390 code, the patch is queued and will be
> included in next weeks please-pull. But I am wondering about the use
> of TASK_SIZE in kernel threads. For x86 copy_mount_options works
> b
->context.asce_limit happened to be close enough to the data
pointer that the 'size' result is a small number, in this case 2.
Now I fixed this in the s390 code, the patch is queued and will be
included in next weeks please-pull. But I am wondering about the use
of TASK_SIZE in kernel
Return a sensible value if TASK_SIZE if called from a kernel thread.
This gets us around an issue with copy_mount_options that does a magic
size calculation "TASK_SIZE - (unsigned long)data" while in a kernel
thread and data pointing to kernel space.
Cc:
Signed-off-by: Martin Schwidefsky
---
a
Am Thu, 18 Aug 2016 10:42:08 -0400
schrieb Tejun Heo :
> Hello, Michael.
>
> On Thu, Aug 18, 2016 at 11:30:51AM +0200, Michael Holzheu wrote:
> > Well, "no requirement" this is not 100% correct. Currently we use
> > the CPU topology information to assign newly coming CPUs to the
> > "best fitting
Hello, Michael.
On Thu, Aug 18, 2016 at 11:30:51AM +0200, Michael Holzheu wrote:
> Well, "no requirement" this is not 100% correct. Currently we use the
> CPU topology information to assign newly coming CPUs to the "best
> fitting" node.
>
> Example:
>
> 1) We have we two fake NUMA nodes N1 and
Am Wed, 17 Aug 2016 09:58:55 -0400
schrieb Tejun Heo :
> Hello, Heiko.
>
> On Wed, Aug 17, 2016 at 12:19:53AM +0200, Heiko Carstens wrote:
> > I think the easiest solution would be to simply assign all cpus,
> > for which we do not have any topology information, to an arbitrary
> > node; e.g. rou
Hello, Heiko.
On Wed, Aug 17, 2016 at 12:19:53AM +0200, Heiko Carstens wrote:
> I think the easiest solution would be to simply assign all cpus, for which
> we do not have any topology information, to an arbitrary node; e.g. round
> robin.
>
> After all the case that cpus are added later is rare
Am Wed, 17 Aug 2016 00:19:53 +0200
schrieb Heiko Carstens :
> On Tue, Aug 16, 2016 at 11:42:05AM -0400, Tejun Heo wrote:
> > Hello, Peter.
> >
> > On Tue, Aug 16, 2016 at 05:29:49PM +0200, Peter Zijlstra wrote:
> > > On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo wrote:
> > > > As long as th
On Tue, Aug 16, 2016 at 11:42:05AM -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, Aug 16, 2016 at 05:29:49PM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo wrote:
> > > As long as the mapping doesn't change after the first onlining of the
> > > CPU, the w
Hello, Peter.
On Tue, Aug 16, 2016 at 05:29:49PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo wrote:
> > As long as the mapping doesn't change after the first onlining of the
> > CPU, the workqueue side shouldn't be too difficult to fix up. I'll
> > look into
On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo wrote:
> As long as the mapping doesn't change after the first onlining of the
> CPU, the workqueue side shouldn't be too difficult to fix up. I'll
> look into it. For memory allocations, as long as the cpu <-> node
> mapping is established befo
Hello, Heiko.
On Tue, Aug 16, 2016 at 09:55:05AM +0200, Heiko Carstens wrote:
...
>
> The new standby cpu will have a "configure" sysfs attribute. If somebody
> writes "1" to it we signal the hypervisor that we want to use the cpu and
> it allocates one. If this request succeeds we finally know wh
Hi Tejun,
> On Mon, Aug 15, 2016 at 01:19:08PM +0200, Heiko Carstens wrote:
> > I can imagine several ways to fix this for s390, but before doing that I'm
> > wondering if the workqueue code is correct with
> >
> > a) assuming that the cpu_to_node() mapping is valid for all _possible_ cpus
> >
Hello, Heiko.
On Mon, Aug 15, 2016 at 01:19:08PM +0200, Heiko Carstens wrote:
> I can imagine several ways to fix this for s390, but before doing that I'm
> wondering if the workqueue code is correct with
>
> a) assuming that the cpu_to_node() mapping is valid for all _possible_ cpus
>that ea
re. Looks like we initialize
> > the cpu_to_node_masks (way) too late on s390 for fake numa. So Peter's
> > patch just revealed that problem.
> >
> > I'll see if initializing the masks earlier will fix this, but I think it
> > will.
>
> Hello,
s simply empty.
>
> Just had some time to look into this a bit more. Looks like we initialize
> the cpu_to_node_masks (way) too late on s390 for fake numa. So Peter's
> patch just revealed that problem.
>
> I'll see if initializing the masks earlier will fix this, but I think it
> will.
Hello,
Is there any fix for this issue? I can see the issue on arm64 running
v4.7 kernel too. And the oops can be avoided by reverting commit
e9d867a(sched: Allow per-cpu kernel threads to run on online && !active).
Thanks,
Ming Lei
On Wed, Jul 27, 2016 at 05:23:05PM +0200, Thomas Gleixner wrote:
> On Wed, 27 Jul 2016, Heiko Carstens wrote:
> > [3.162961] ([<00176c30>] select_task_rq+0xc0/0x1a8)
> > [3.162963] ([<00177d64>] try_to_wake_up+0x2e4/0x478)
> > [3.162968] ([<0015d46c>] create_work
On Wed, 27 Jul 2016, Heiko Carstens wrote:
> [3.162961] ([<00176c30>] select_task_rq+0xc0/0x1a8)
> [3.162963] ([<00177d64>] try_to_wake_up+0x2e4/0x478)
> [3.162968] ([<0015d46c>] create_worker+0x174/0x1c0)
> [3.162971] ([<00161a98>] alloc_unbound_pwq+
Hi Peter,
I get the following warning on s390 when using fake NUMA beginning with
your patch
e9d867a67fd0 "sched: Allow per-cpu kernel threads to run on online && !active"
[3.162909] WARNING: CPU: 0 PID: 1 at include/linux/cpumask.h:121
select_task_rq+0xe6/0x1a8
[
1 - 100 of 375 matches
Mail list logo
