On Wed, Apr 07, 2021 at 05:51:07PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> > Further, it is not the case that RISC-V has no guarantees at all.
> > It just does not provide a forward progress guarantee for a
>
On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> RISC-V defines LR/SC loops consisting of up to 16 instructions as
> constrained LR/SC loops. Such constrained LR/SC loops provide the
> required forward guarantees, that are expected (similar to what other
> architectures, like
On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> The comparison with sparc64 is not applicable, as sparc64 does not
> have LL/SC instructions.
Sparc64 has CAS, without hardware fwd progress. It has to do software
backoff for failed CAS in order to do software fwd progress.
On Wed, Apr 07, 2021 at 04:29:12PM +0200, Christoph Müllner wrote:
> Further, it is not the case that RISC-V has no guarantees at all.
> It just does not provide a forward progress guarantee for a
> synchronization implementation,
> that writes in an endless loop to a memory location while trying
On Mon, Mar 29, 2021 at 01:41:30PM +0800, Like Xu wrote:
> @@ -3863,6 +3864,12 @@ static struct perf_guest_switch_msr
> *intel_guest_get_msrs(int *nr, void *data)
> arr[2].host = (unsigned long)ds;
> arr[2].guest = pmu->ds_area;
*nr = 3;
>
> +
On Mon, Mar 29, 2021 at 01:41:29PM +0800, Like Xu wrote:
> @@ -3869,10 +3876,12 @@ static struct perf_guest_switch_msr
> *intel_guest_get_msrs(int *nr, void *data)
>
> if (arr[1].guest)
> arr[0].guest |= arr[1].guest;
> - else
> + else
On Mon, Mar 29, 2021 at 01:41:28PM +0800, Like Xu wrote:
> + if (vcpu->arch.perf_capabilities & PERF_CAP_PEBS_FORMAT) {
> + if (vcpu->arch.perf_capabilities & PERF_CAP_PEBS_BASELINE) {
> + pmu->pebs_enable_mask = ~pmu->global_ctrl;
> +
On Tue, Apr 06, 2021 at 06:44:36PM -0700, Michel Lespinasse wrote:
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1219,6 +1219,8 @@ void do_user_addr_fault(struct pt_regs *regs,
> struct mm_struct *mm;
> vm_fault_t fault;
> unsigned int flags = FAULT_FLAG_DEFAULT;
On Tue, Apr 06, 2021 at 06:44:34PM -0700, Michel Lespinasse wrote:
> The counter's write side is hooked into the existing mmap locking API:
> mmap_write_lock() increments the counter to the next (odd) value, and
> mmap_write_unlock() increments it again to the next (even) value.
>
> The counter's
On Tue, Apr 06, 2021 at 06:44:49PM -0700, Michel Lespinasse wrote:
> In the speculative case, call the vm_ops->fault() method from within
> an rcu read locked section, and verify the mmap sequence lock at the
> start of the section. A match guarantees that the original vma is still
> valid at that
On Tue, Apr 06, 2021 at 10:54:23AM -0500, Josh Poimboeuf wrote:
> Same for Red Hat. Unloading livepatch modules seems to work fine, but
> isn't officially supported.
>
> That said, if rmmod is just considered a development aid, and we're
> going to be ignoring bugs, we should make it official
On Wed, Apr 07, 2021 at 11:46:43AM +0100, Valentin Schneider wrote:
> On 26/03/21 11:33, Peter Zijlstra wrote:
> > __read_mostly bool sched_debug_enabled;
> >
> > +struct dentry *debugfs_sched;
> > +
> > static __init int sched_init_debug(void)
&
On Wed, Apr 07, 2021 at 11:46:32AM +0100, Valentin Schneider wrote:
> > - __cpumask_clear_cpu(i, sd_sysctl_cpus);
>
> That seems to be the only place we cleared a CPU in that cpumask, and I
> don't see its replacement
Yeah, oops :-) Lemme go fix that. Thanks!
On Wed, Apr 07, 2021 at 11:47:17AM +0100, Mel Gorman wrote:
> Ok, cpusets do split domains. I can't imagine the logic of splitting SMT
> siblings across cpusets but if it's possible, it has to be checked and
> protecting that with cpusets_enabled() would be a little overkill and
> possibly miss
On Wed, Apr 07, 2021 at 01:36:45PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 07, 2021 at 10:42:50AM +0200, Arnd Bergmann wrote:
> > Since there are really only a handful of instances in the kernel
> > that use the cmpxchg() or xchg() on u8/u16 variables, it would seem
> >
On Wed, Apr 07, 2021 at 10:42:50AM +0200, Arnd Bergmann wrote:
> Since there are really only a handful of instances in the kernel
> that use the cmpxchg() or xchg() on u8/u16 variables, it would seem
> best to just disallow those completely
Not going to happen. xchg16 is optimal for qspinlock
On Wed, Apr 07, 2021 at 11:54:37AM +0200, Peter Zijlstra wrote:
> Let me have another poke at it.
Pretty much what you did, except I also did s/smt/has_idle_core/ and
fixed that @sd thing.
Like so then?
---
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6038,11 +6038,9 @@ sta
On Wed, Apr 07, 2021 at 10:41:06AM +0100, Mel Gorman wrote:
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -6112,6 +6112,27 @@ static int select_idle_core(struct task_
> > return -1;
> > }
> >
> > +/*
> > + * Scan the local SMT mask for idle CPUs.
> > + */
> > +static
On Wed, Apr 07, 2021 at 11:42:17AM +0200, Vincent Guittot wrote:
> I would really prefer to keep that out of select_idle_cpu which aims to merge
> in one
> single loop the walk through sd_llc. In the case of select_idle_smt, this is
> done outside
> the loop:
Fair enough.
> @@ -6317,11
On Wed, Apr 07, 2021 at 08:52:08AM +0900, Stafford Horne wrote:
> Why doesn't RISC-V add the xchg16 emulation code similar to OpenRISC? For
> OpenRISC we added xchg16 and xchg8 emulation code to enable qspinlocks. So
> one thought is with CONFIG_ARCH_USE_QUEUED_SPINLOCKS_XCHG32=y, can we remove
On Wed, Apr 07, 2021 at 01:24:12AM +0800, Boqun Feng wrote:
> Actually, "old" riscv standard does provide fwd progress ;-) In
>
> https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
>
> Section "7.2 Load-Reserved/Store-Conditional Instructions":
>
> """
> One advantage of
On Mon, Mar 29, 2021 at 01:41:28PM +0800, Like Xu wrote:
> diff --git a/arch/x86/include/asm/msr-index.h
> b/arch/x86/include/asm/msr-index.h
> index 546d6ecf0a35..9afcad882f4f 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -186,6 +186,12 @@
>
On Mon, Mar 29, 2021 at 01:41:27PM +0800, Like Xu wrote:
> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> index 827886c12c16..3509b18478b9 100644
> --- a/arch/x86/kvm/pmu.c
> +++ b/arch/x86/kvm/pmu.c
> @@ -74,11 +74,20 @@ static void kvm_perf_overflow_intr(struct perf_event
>
On Tue, Apr 06, 2021 at 07:43:53PM +0200, Oleg Nesterov wrote:
> On 04/06, Oleg Nesterov wrote:
> >
> > perf_mmap_close() was added by 9bb5d40cd93c9 ("perf: Fix mmap() accounting
> > hole")
>
> I meant perf_mmap_close() -> put_event()
>
> > and this commit doesn't look right anyway
>
> It
9 response times for
the memcache type application improve by about 10% over what they were
before Mel's patches got merged.
Signed-off-by: Rik van Riel
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210326151932.2c187...@imladris.surri
On Mon, Mar 29, 2021 at 01:41:23PM +0800, Like Xu wrote:
> With PEBS virtualization, the guest PEBS records get delivered to the
> guest DS, and the host pmi handler uses perf_guest_cbs->is_in_guest()
> to distinguish whether the PMI comes from the guest code like Intel PT.
>
> No matter how many
On Sun, Apr 04, 2021 at 07:39:03PM -0400, Tejun Heo wrote:
> cc'ing Michal and Christian who've been spending some time on cgroup
> interface issues recently and Li Zefan for cpuset.
>
> On Thu, Apr 01, 2021 at 03:10:12PM +0200, Peter Zijlstra wrote:
> > The cgroup
On Fri, Apr 02, 2021 at 06:30:48PM -0700, Josh Don wrote:
> Hi Peter,
>
> I walked through the reference counting, and it seems good to me
> (though it did take a few passes to fully digest the invariants for
> the fat cookie stuff).
>
> > +unsigned long sched_core_alloc_cookie(unsigned int
On Mon, Apr 05, 2021 at 09:11:07PM -0700, Ricardo Neri wrote:
> @@ -8507,6 +8619,10 @@ static bool update_sd_pick_busiest(struct lb_env *env,
> if (!sgs->sum_h_nr_running)
> return false;
>
> + if (sgs->group_type == group_asym_packing &&
> +
On Mon, Apr 05, 2021 at 09:11:07PM -0700, Ricardo Neri wrote:
> +static bool cpu_group_is_smt(int cpu, struct sched_group *sg)
> +{
> +#ifdef CONFIG_SCHED_SMT
> + if (!static_branch_likely(_smt_present))
> + return false;
> +
> + if (sg->group_weight == 1)
> +
On Mon, Apr 05, 2021 at 04:00:36PM -0700, Mike Kravetz wrote:
> The lock doesn't protect any sleepable operation so it can be changed to
> a (irq aware) spin lock. The bitmap processing should be quite fast in
> typical case but if cma sizes grow to TB then we will likely need to
> replace the
On Mon, Apr 05, 2021 at 07:42:03PM -0400, Waiman Long wrote:
> The handling of sysrq key can be activated by echoing the key to
> /proc/sysrq-trigger or via the magic key sequence typed into a terminal
> that is connected to the system in some way (serial, USB or other mean).
> In the former case,
On Sun, Apr 04, 2021 at 11:24:57AM +0100, Matthew Wilcox wrote:
> On Sat, Apr 03, 2021 at 09:15:17PM -0700, syzbot wrote:
> > HEAD commit:2bb25b3a Merge tag 'mips-fixes_5.12_3' of git://git.kernel..
> > git tree: upstream
> > console output:
On Wed, Mar 31, 2021 at 11:57:23AM +0200, Dmitry Vyukov wrote:
> On Wed, Mar 31, 2021 at 9:31 AM Peter Zijlstra wrote:
> >
> > On Wed, Mar 31, 2021 at 08:11:38AM +0200, Dmitry Vyukov wrote:
> > > On Wed, Mar 31, 2021 at 12:26 AM syzbot
> > > wrote:
> > &g
On Wed, Mar 31, 2021 at 11:22:35PM +0800, Guo Ren wrote:
> On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >
> > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > u32 a = 0x55aa66bb;
> > > u16 *ptr =
> >
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 119251855f9adf9421cb5eb409933092141ab2c7
Gitweb:
https://git.kernel.org/tip/119251855f9adf9421cb5eb409933092141ab2c7
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:02 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 23c1ad538f4f371bdb67d8a112314842d5db7e5a
Gitweb:
https://git.kernel.org/tip/23c1ad538f4f371bdb67d8a112314842d5db7e5a
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:01 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 530b4ddd9dd92b263081f5c7786d39a8129c8b2d
Gitweb:
https://git.kernel.org/tip/530b4ddd9dd92b263081f5c7786d39a8129c8b2d
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:04 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: bcb1b6ff39da7e8a6a986eb08126fba2b5e13c32
Gitweb:
https://git.kernel.org/tip/bcb1b6ff39da7e8a6a986eb08126fba2b5e13c32
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:03 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 3a647607b57ad8346e659ddd3b951ac292c83690
Gitweb:
https://git.kernel.org/tip/3a647607b57ad8346e659ddd3b951ac292c83690
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:06 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: a958c4fea768d2c378c89032ab41d38da2a24422
Gitweb:
https://git.kernel.org/tip/a958c4fea768d2c378c89032ab41d38da2a24422
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:05 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: d0c5c4cc73da0b05b0d9e5f833f2d859e1b45f8e
Gitweb:
https://git.kernel.org/tip/d0c5c4cc73da0b05b0d9e5f833f2d859e1b45f8e
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:08 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: ef47cc01cb4abcd760d8ac66b9361d6ade4d0846
Gitweb:
https://git.kernel.org/tip/ef47cc01cb4abcd760d8ac66b9361d6ade4d0846
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:07 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 417a4dc91e559f92404c2544f785b02ce75784c3
Gitweb:
https://git.kernel.org/tip/417a4dc91e559f92404c2544f785b02ce75784c3
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:09 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 9a7827b7789c630c1efdb121daa42c6e77dce97f
Gitweb:
https://git.kernel.org/tip/9a7827b7789c630c1efdb121daa42c6e77dce97f
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:10 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 9bc0bb50727c8ac69fbb33fb937431cf3518ff37
Gitweb:
https://git.kernel.org/tip/9bc0bb50727c8ac69fbb33fb937431cf3518ff37
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:15 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 43d5430ad74ef5156353af7aec352426ec7a8e57
Gitweb:
https://git.kernel.org/tip/43d5430ad74ef5156353af7aec352426ec7a8e57
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:12 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 7bd2a600f3e9d27286bbf23c83d599e9cc7cf245
Gitweb:
https://git.kernel.org/tip/7bd2a600f3e9d27286bbf23c83d599e9cc7cf245
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:13 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 2f2f7e47f0525cbaad5dd9675fd9d8aa8da12046
Gitweb:
https://git.kernel.org/tip/2f2f7e47f0525cbaad5dd9675fd9d8aa8da12046
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:11 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 50e7b4a1a1b264fc7df0698f2defb93cadf19a7b
Gitweb:
https://git.kernel.org/tip/50e7b4a1a1b264fc7df0698f2defb93cadf19a7b
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:14 +01:00
On Thu, Apr 01, 2021 at 01:04:58PM -0700, Josh Don wrote:
> > +/*
> > + * sched_core_update_cookie - Common helper to update a task's core
> > cookie. This
> > + * updates the selected cookie field.
> > + * @p: The task whose cookie should be updated.
> > + * @cookie: The new cookie.
> > + *
The following commit has been merged into the x86/core branch of tip:
Commit-ID: b62b63571e4be0ce31984ce83b04853f2cba678b
Gitweb:
https://git.kernel.org/tip/b62b63571e4be0ce31984ce83b04853f2cba678b
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:05 +01:00
cookies is ensured by use of a global tree.
Due to the locking rules for cookies, the need for fat cookies is not
apparent up-front, nor can they be allocated in-situ, therefore
pre-allocate them agressively and mostly free them instantly when not
used.
Signed-off-by: Peter Zijlstra (Intel
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 4ecdc0265dc911adba0772fd6e816d48da678fe7
Gitweb:
https://git.kernel.org/tip/4ecdc0265dc911adba0772fd6e816d48da678fe7
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:13 +01:00
On Wed, Mar 31, 2021 at 09:11:27AM +0200, Peter Zijlstra wrote:
> On Tue, Mar 30, 2021 at 02:29:06PM -0700, Josh Don wrote:
> > On Mon, Mar 29, 2021 at 2:55 AM Peter Zijlstra wrote:
> > >
> > > OK, fixed the fails. My tired head made it unconditionally return the
This allows the rb_find_add() comparator to modify existing entries.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/rbtree.h |2 +-
kernel/events/uprobes.c |2 +-
tools/include/linux/rbtree.h |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- a/include
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 98ce4d014ad4c1c4afcc427fc3f0002674315cb9
Gitweb:
https://git.kernel.org/tip/98ce4d014ad4c1c4afcc427fc3f0002674315cb9
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:06 +01:00
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/sched/core.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -268,18 +268,24 @@ static void __sched_core_flip(bool enabl
cpus_read_unlock();
}
-static
In order to not have to use pid_struct, create a new, smaller,
structure to manage task cookies for core scheduling.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/sched.h |6 ++
kernel/fork.c |1
kernel/sched/Makefile |1
kernel/sched/core.c
, and
not from sched_fork() earlier. This avoids a few races later.
Signed-off-by: Peter Zijlstra (Intel)
---
fs/exec.c |4 +++-
include/linux/sched.h |4
include/linux/sched/task.h |4 ++--
kernel/fork.c |3 +++
kernel/sched/core.c| 11
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 52fa82c21f64e900a72437269a5cc9e0034b424e
Gitweb:
https://git.kernel.org/tip/52fa82c21f64e900a72437269a5cc9e0034b424e
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:00 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: b4da5166b084f3fac01d68e0e67cbf3bf78a3e12
Gitweb:
https://git.kernel.org/tip/b4da5166b084f3fac01d68e0e67cbf3bf78a3e12
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:01 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: db9d1dd670d7f3f146c654f289f20968af6a12de
Gitweb:
https://git.kernel.org/tip/db9d1dd670d7f3f146c654f289f20968af6a12de
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:03 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: d56a3568827ec4b8efcbcfc46fdc944995b6dcf1
Gitweb:
https://git.kernel.org/tip/d56a3568827ec4b8efcbcfc46fdc944995b6dcf1
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:10 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: f31390437ce984118215169d75570e365457ec23
Gitweb:
https://git.kernel.org/tip/f31390437ce984118215169d75570e365457ec23
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:15 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 557c25be3588971caf21364b6fd240769e37c47c
Gitweb:
https://git.kernel.org/tip/557c25be3588971caf21364b6fd240769e37c47c
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:09 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 3b652980a250c1ed9e0c361750f029781831cdc3
Gitweb:
https://git.kernel.org/tip/3b652980a250c1ed9e0c361750f029781831cdc3
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:04 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 7508e2958a82675e75e34221c26ad4242d4ef283
Gitweb:
https://git.kernel.org/tip/7508e2958a82675e75e34221c26ad4242d4ef283
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:07 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: aef0f13e96db08f31be6b96d28e761df46d86ff4
Gitweb:
https://git.kernel.org/tip/aef0f13e96db08f31be6b96d28e761df46d86ff4
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:08 +01:00
ess they can set a cookie for.
Lack of a cookie *might* be a security issue if cookies are being used
for that.
[peterz: complete rewrite]
Signed-off-by: Chris Hyser
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210324214020.34142-4-j...@joelfernandes.org
---
incl
Hi,
This is a rewrite of the core sched interface bits, and mostly replaces patches
2-5 from this set here:
https://lkml.kernel.org/r/20210324214020.34142-1-j...@joelfernandes.org
The task interface is extended to include PR_SCHED_CORE_GET, because the
selftest. Otherwise the task interface
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 68a59124f4c6363de619fea63231a97dd220a12c
Gitweb:
https://git.kernel.org/tip/68a59124f4c6363de619fea63231a97dd220a12c
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:14 +01:00
Stuff the meat of sched_core_put() into a work such that we can use
sched_core_put() from atomic context.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/sched/core.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
--- a/kernel/sched/core.c
+++ b
ss->attach() being 'atomic', which is hard to do without cgroup_mutex.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/sched/core.c | 150 +++
kernel/sched/sched.h |7 ++
2 files changed, 157 insertions(+)
--- a/kernel/sched/core.c
+++ b/
From: Chris Hyser
Provides a selftest and examples of using the interface.
[peterz: updated to not use sched_debug]
Signed-off-by: Chris Hyser
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210324214020.34142-5-j...@joelfernandes.org
---
tools/testing/selftests/sched
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 993b477acdb652c6134e5faae05e8a378911cbb3
Gitweb:
https://git.kernel.org/tip/993b477acdb652c6134e5faae05e8a378911cbb3
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:11 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 7e57a6bc5a22145429d3a232619b0637c312397a
Gitweb:
https://git.kernel.org/tip/7e57a6bc5a22145429d3a232619b0637c312397a
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:12 +01:00
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 2077915516ebb06d36e03cb542ccb833a8b0a3eb
Gitweb:
https://git.kernel.org/tip/2077915516ebb06d36e03cb542ccb833a8b0a3eb
Author:Peter Zijlstra
AuthorDate:Fri, 26 Mar 2021 16:12:02 +01:00
On Wed, Mar 31, 2021 at 11:31:56PM -0400, Josh Hunt wrote:
> Currently only root can write files under /proc/pressure. Relax this to
> allow tasks running as unprivileged users with CAP_SYS_RESOURCE to be
> able to write to these files.
>
> Signed-off-by: Josh Hunt
I suppose that's ok, but lets
On Wed, Mar 31, 2021 at 02:32:58PM +0200, Marco Elver wrote:
> On Mon, 29 Mar 2021 at 14:07, Peter Zijlstra wrote:
>
> > (and we might already have a problem on some architectures where there
> > can be significant time between these due to not having
> > arch_irq_wor
On Wed, Mar 31, 2021 at 02:15:41PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5e46d1b78a03d52306f21f77a4e4a144b6d31486
> commit: 826bfeb37bb4302ee6042f330c4c0c757152bdb8 preempt/dynamic: Support
> dynamic
On Wed, Mar 31, 2021 at 08:11:38AM +0200, Dmitry Vyukov wrote:
> On Wed, Mar 31, 2021 at 12:26 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:db24726b Merge tag 'integrity-v5.12-fix' of git://git.kern..
> > git tree: upstream
> >
On Tue, Mar 30, 2021 at 02:29:06PM -0700, Josh Don wrote:
> On Mon, Mar 29, 2021 at 2:55 AM Peter Zijlstra wrote:
> >
> > OK, fixed the fails. My tired head made it unconditionally return the
> > cookie-id of 'current' instead of task. Pushed out an update.
>
>
On Tue, Mar 30, 2021 at 11:13:55AM +0800, Guo Ren wrote:
> On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >
> > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > u32 a = 0x55aa66bb;
> > > u16 *ptr =
> >
*sigh*, +tj
On Tue, Mar 30, 2021 at 11:23:10AM +0200, Peter Zijlstra wrote:
> On Wed, Mar 24, 2021 at 05:40:17PM -0400, Joel Fernandes (Google) wrote:
> > From: Josh Don
> >
> > This adds the API to set/get the cookie for a given cgroup. This
> > interface l
On Wed, Mar 24, 2021 at 05:40:17PM -0400, Joel Fernandes (Google) wrote:
> From: Josh Don
>
> This adds the API to set/get the cookie for a given cgroup. This
> interface lives at cgroup/cpu.core_tag.
>
> The cgroup interface can be used to toggle a unique cookie value for all
> descendent
On Mon, Mar 29, 2021 at 04:32:18PM +0200, Marco Elver wrote:
> On Mon, 29 Mar 2021 at 16:27, Oleg Nesterov wrote:
> > On 03/29, Peter Zijlstra wrote:
> > >
> > > On Thu, Mar 25, 2021 at 09:14:39AM +0100, Marco Elver wrote:
> > > > @@ -6395,6 +6395,13 @@ sta
On Mon, Mar 29, 2021 at 12:13:10PM +, Anup Patel wrote:
> We had discussions in the RISC-V platforms group about this. Over there,
> We had evaluated all spin lock approaches (ticket, qspinlock, etc) tried
> in Linux till now. It was concluded in those discussions that eventually we
> have to
On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> u32 a = 0x55aa66bb;
> u16 *ptr =
>
> CPU0 CPU1
> = =
> xchg16(ptr, new) while(1)
> WRITE_ONCE(*(ptr + 1), x);
>
> When we use lr.w/sc.w implement
On Thu, Mar 25, 2021 at 09:14:39AM +0100, Marco Elver wrote:
> On Wed, Mar 24, 2021 at 12:24PM +0100, Marco Elver wrote:
> [...]
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index b6434697c516..1e4c949bf75f 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
>
On Thu, Mar 25, 2021 at 08:10:51PM +0100, Marco Elver wrote:
> and therefore synthesized this fix on top:
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 57de8d436efd..e77294c7e654 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -12400,7 +12400,7 @@
On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote:
> Anyway, an additional 'funny' is that I suspect you cannot prove fwd
> progress of the entire primitive with any of this on. But who cares
> about details anyway.. :/
What's the architectural guarantee on LL/SC progress f
On Mon, Mar 29, 2021 at 07:19:29PM +0800, Guo Ren wrote:
> On Mon, Mar 29, 2021 at 3:50 PM Peter Zijlstra wrote:
> >
> > On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> > > From: Guo Ren
> > >
> > > Some architectures d
On Mon, Mar 29, 2021 at 11:23:45AM +0100, Daniel Thompson wrote:
> On Sat, Mar 27, 2021 at 07:25:28PM -0400, Waiman Long wrote:
> > The sched_debug_lock was used only in print_cpu(). The
> > print_cpu() function has two callers - sched_debug_show() and
> > sysrq_sched_debug_show(). Both of them
On Mon, Mar 29, 2021 at 11:41:19AM +0200, Arnd Bergmann wrote:
> On Mon, Mar 29, 2021 at 9:52 AM Peter Zijlstra wrote:
> > On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> > > From: Guo Ren
> > >
> > > Some architectures don't h
ocking/Makefile |2
> kernel/locking/rtmutex.c | 402
> ++-
> kernel/locking/rtmutex_common.h | 104 +-
> 7 files changed, 202 insertions(+), 595 deletions(-)
Acked-by: Peter Zijlstra (Intel)
On Fri, Mar 26, 2021 at 08:19:57PM -0700, Josh Don wrote:
> On Fri, Mar 26, 2021 at 5:10 PM Peter Zijlstra wrote:
> > I've spend the past few hours rewriting patches #2 and #3, and adapting
> > #4. The thing was working before I added SHARE_FROM back and introduced
> > GE
On Sat, Mar 27, 2021 at 06:06:38PM +, guo...@kernel.org wrote:
> From: Guo Ren
>
> Some architectures don't have sub-word swap atomic instruction,
> they only have the full word's one.
>
> The sub-word swap only improve the performance when:
> NR_CPUS < 16K
> * 0- 7: locked byte
> *
On Sat, Mar 27, 2021 at 08:46:10PM +0800, Xie XiuQi wrote:
> s/exceution/execution/
> s/possibe/possible/
> s/manupulations/manipulations/
>
> Signed-off-by: Xie XiuQi
Xie, if you'd have bothered to check the development tree of the code
you're patching, you'd have found it's long since fixed.
On Sun, Mar 28, 2021 at 01:53:15AM +0100, Thomas Gleixner wrote:
> Though the little devil in my head tells me, that making AMX support
> depend on the CPUID faulting capability might be not the worst thing.
>
> Then we actually enforce CPUID faulting (finally) on CPUs which support
> it, which
201 - 300 of 42288 matches
Mail list logo
