On 5/3/24 17:10, David Laight wrote:
From: Waiman Long
Sent: 03 May 2024 17:00
...
David,
Could you respin the series based on the latest upstream code?
I've just reapplied the patches to 'master' and they all apply
cleanly and diffing the new patches to the old ones gives no differences
On 12/31/23 23:14, Waiman Long wrote:
On 12/31/23 16:55, David Laight wrote:
per_cpu_ptr() indexes __per_cpu_offset[] with the cpu number.
This requires the cpu number be 64bit.
However the value is osq_lock() comes from a 32bit xchg() and there
isn't a way of telling gcc the high bits
On 3/20/24 12:20, Steven Rostedt wrote:
From: Steven Rostedt (Google)
I'm debugging some latency issues on a Chromebook and the preemptirqsoff
tracer hit this:
# tracer: preemptirqsoff
#
# preemptirqsoff latency trace v1.1.5 on 5.15.148-21853-g165fd2387469-dirty
#
, encoded_cpu_val - 1);
}
/*
You really like micro-optimization.
Anyway,
Reviewed-by: Waiman Long
de->prev_cpu = prev_cpu;
+ node = this_cpu_ptr(_node);
prev = decode_cpu(prev_cpu);
+ node->prev_cpu = prev_cpu;
node->locked = 0;
/*
Reviewed-by: Waiman Long
on in the kernel to add another
nesting level just to reduce the scope of new_prev_cpu auto variable.
Anyway,
Reviewed-by: Waiman Long
@@ -201,6 +198,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
* it will wait in Step-A.
*/
+ WRITE_ONCE(next->prev_cpu, prev->cpu);
WRITE_ONCE(next->prev, prev);
WRITE_ONCE(prev->next, next);
Reviewed-by: Waiman Long
Reviewed-by: Waiman Long
= prev;
Reviewed-by: Waiman Long
On 12/30/23 06:35, David Laight wrote:
From: Ingo Molnar
Sent: 30 December 2023 11:09
* Waiman Long wrote:
On 12/29/23 15:57, David Laight wrote:
this_cpu_ptr() is rather more expensive than raw_cpu_read() since
the latter can use an 'offset from register' (%gs for x86-84).
Add a 'self
On 12/30/23 17:39, David Laight wrote:
From: Linus Torvalds
Sent: 30 December 2023 19:41
On Fri, 29 Dec 2023 at 12:52, David Laight wrote:
David Laight (5):
Move the definition of optimistic_spin_node into osf_lock.c
Clarify osq_wait_next()
I took these two as preparatory
On 12/29/23 22:13, Waiman Long wrote:
On 12/29/23 15:58, David Laight wrote:
The vcpu_is_preempted() test stops osq_lock() spinning if a virtual
cpu is no longer running.
Although patched out for bare-metal the code still needs the cpu number.
Reading this from 'prev->cpu' is a pretty m
On 12/29/23 17:11, David Laight wrote:
osq_lock() starts by setting node->next to NULL and node->locked to 0.
Careful analysis shows that node->next is always NULL on entry.
node->locked is set non-zero by another cpu to force a wakeup.
This can only happen after the 'prev->next = node'
*lock)
* it will wait in Step-A.
*/
+ WRITE_ONCE(next->prev_cpu, prev->cpu - 1);
WRITE_ONCE(next->prev, prev);
WRITE_ONCE(prev->next, next);
Reviewed-by: Waiman Long
On 12/29/23 15:57, David Laight wrote:
this_cpu_ptr() is rather more expensive than raw_cpu_read() since
the latter can use an 'offset from register' (%gs for x86-84).
Add a 'self' field to 'struct optimistic_spin_node' that can be
read with raw_cpu_read(), initialise on first call.
On 12/29/23 15:56, David Laight wrote:
osq_wait_next() is passed 'prev' from osq_lock() and NULL from osq_unlock()
but only needs the 'cpu' value to write to lock->tail.
Just pass prev->cpu or OSQ_UNLOCKED_VAL instead.
Also directly return NULL or 'next' instead of breaking the loop.
Should
c".
After the fix, you can add
Acked-by: Waiman Long
On 4/13/22 02:01, Dan Williams wrote:
Changes since v1 [1]:
- Improve the clarity of the cover letter and changelogs of the
major patches (Patch2 and Patch12) (Pierre, Kevin, and Dave)
- Fix device_lock_interruptible() false negative deadlock detection
(Kevin)
- Fix off-by-one error in the
of calls to __mod_objcg_state()
by more than 80%.
Signed-off-by: Waiman Long
Reviewed-by: Shakeel Butt
---
mm/memcontrol.c | 86 +++--
1 file changed, 83 insertions(+), 3 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7cd7187a017c
(cgroup v2).
Signed-off-by: Waiman Long
---
mm/memcontrol.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 292b4783b1a7..2f87d0b05092 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3153,10 +3153,12
4 helps in cgroup v2, but performs worse in cgroup v1 as
eliminating the irq_disable/irq_enable overhead seems to aggravate the
cacheline contention.
[1] https://lore.kernel.org/linux-mm/20210408193948.vfktg3azh2wrt56t@gabell/T/#u
[2] https://lore.kernel.org/lkml/20210114025151.GA22932@xsang-OptiPlex-9020/
The mod_objcg_state() function is moved from mm/slab.h to mm/memcontrol.c
so that further optimization can be done to it in later patches without
exposing unnecessary details to other mm components.
Signed-off-by: Waiman Long
Acked-by: Johannes Weiner
---
mm/memcontrol.c | 13 +
mm
price to pay for better performance.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
mm/memcontrol.c | 94 +++--
1 file changed, 68 insertions(+), 26 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index
On 4/19/21 12:55 PM, Johannes Weiner wrote:
On Sun, Apr 18, 2021 at 08:00:31PM -0400, Waiman Long wrote:
Currently, the object stock structure caches either reclaimable vmstat
bytes or unreclaimable vmstat bytes in its object stock structure. The
hit rate can be improved if both types of vmstat
On 4/19/21 12:38 PM, Johannes Weiner wrote:
On Sun, Apr 18, 2021 at 08:00:29PM -0400, Waiman Long wrote:
Before the new slab memory controller with per object byte charging,
charging and vmstat data update happen only when new slab pages are
allocated or freed. Now they are done with every
On 4/19/21 5:11 PM, Johannes Weiner wrote:
BTW, have you ever thought of moving the cgroup-v1 specific functions out
into a separate memcontrol-v1.c file just like kernel/cgroup/cgroup-v1.c?
I thought of that before, but memcontrol.c is a frequently changed file and
so a bit hard to do.
I
On 4/19/21 1:19 PM, Waiman Long wrote:
On 4/19/21 1:13 PM, Johannes Weiner wrote:
On Mon, Apr 19, 2021 at 12:18:29PM -0400, Waiman Long wrote:
On 4/19/21 11:21 AM, Waiman Long wrote:
On 4/19/21 11:14 AM, Johannes Weiner wrote:
On Sun, Apr 18, 2021 at 08:00:28PM -0400, Waiman Long wrote
On 4/19/21 1:13 PM, Johannes Weiner wrote:
On Mon, Apr 19, 2021 at 12:18:29PM -0400, Waiman Long wrote:
On 4/19/21 11:21 AM, Waiman Long wrote:
On 4/19/21 11:14 AM, Johannes Weiner wrote:
On Sun, Apr 18, 2021 at 08:00:28PM -0400, Waiman Long wrote:
The mod_objcg_state() function is moved
On 4/19/21 11:21 AM, Waiman Long wrote:
On 4/19/21 11:14 AM, Johannes Weiner wrote:
On Sun, Apr 18, 2021 at 08:00:28PM -0400, Waiman Long wrote:
The mod_objcg_state() function is moved from mm/slab.h to
mm/memcontrol.c
so that further optimization can be done to it in later patches without
On 4/19/21 2:06 AM, Muchun Song wrote:
On Mon, Apr 19, 2021 at 8:01 AM Waiman Long wrote:
There are two issues with the current refill_obj_stock() code. First of
all, when nr_bytes reaches over PAGE_SIZE, it calls drain_obj_stock() to
atomically flush out remaining bytes to obj_cgroup, clear
On 4/19/21 11:14 AM, Johannes Weiner wrote:
On Sun, Apr 18, 2021 at 08:00:28PM -0400, Waiman Long wrote:
The mod_objcg_state() function is moved from mm/slab.h to mm/memcontrol.c
so that further optimization can be done to it in later patches without
exposing unnecessary details to other mm
On 4/19/21 11:00 AM, Shakeel Butt wrote:
On Sun, Apr 18, 2021 at 11:07 PM Muchun Song wrote:
On Mon, Apr 19, 2021 at 8:01 AM Waiman Long wrote:
There are two issues with the current refill_obj_stock() code. First of
all, when nr_bytes reaches over PAGE_SIZE, it calls drain_obj_stock
tup. However,
the miss rate for parallel kernel build remained about the same probably
because most of the touched kmemcache objects were reclaimable inodes
and dentries.
Signed-off-by: Waiman Long
---
mm/memcontrol.c | 79 +++--
1 file changed,
,
a new overfill flag is added to refill_obj_stock() which will be set
when called from obj_cgroup_charge().
Signed-off-by: Waiman Long
---
mm/memcontrol.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index
is code path isn't being exercised. The
large object test, however, sees a pretty good performance improvement
with this patch.
[1] https://lore.kernel.org/linux-mm/20210408193948.vfktg3azh2wrt56t@gabell/T/#u
[2] https://lore.kernel.org/lkml/20210114025151.GA22932@xsang-OptiPlex-9020/
Waiman Lo
price to pay for better performance.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
mm/memcontrol.c | 94 +++--
1 file changed, 68 insertions(+), 26 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index
of calls to __mod_objcg_state()
by more than 80%.
Signed-off-by: Waiman Long
Reviewed-by: Shakeel Butt
---
mm/memcontrol.c | 64 ++---
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index dc9032f28f2e
The mod_objcg_state() function is moved from mm/slab.h to mm/memcontrol.c
so that further optimization can be done to it in later patches without
exposing unnecessary details to other mm components.
Signed-off-by: Waiman Long
---
mm/memcontrol.c | 13 +
mm/slab.h | 16
ed if truncation may have
happened. The cgroup path name is provided for informational purpose
only, so occasional path name truncation should not be a big problem.
Fixes: efe25c2c7b3a ("sched: Reinstate group names in /proc/sched_debug")
Suggested-by: Peter Zijlstra
Signed-off-by: Waim
On 4/15/21 3:40 PM, Johannes Weiner wrote:
On Thu, Apr 15, 2021 at 02:47:31PM -0400, Waiman Long wrote:
On 4/15/21 2:10 PM, Johannes Weiner wrote:
On Thu, Apr 15, 2021 at 12:35:45PM -0400, Waiman Long wrote:
On 4/15/21 12:30 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:24PM -0400
On 4/15/21 2:53 PM, Johannes Weiner wrote:
On Thu, Apr 15, 2021 at 02:16:17PM -0400, Waiman Long wrote:
On 4/15/21 1:53 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:27PM -0400, Waiman Long wrote:
Most kmem_cache_alloc() calls are from user context. With instrumentation
enabled
On 4/15/21 2:10 PM, Johannes Weiner wrote:
On Thu, Apr 15, 2021 at 12:35:45PM -0400, Waiman Long wrote:
On 4/15/21 12:30 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:24PM -0400, Waiman Long wrote:
In memcg_slab_free_hook()/pcpu_memcg_free_hook(), obj_cgroup_uncharge()
is followed
On 4/15/21 1:53 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:27PM -0400, Waiman Long wrote:
Most kmem_cache_alloc() calls are from user context. With instrumentation
enabled, the measured amount of kmem_cache_alloc() calls from non-task
context was about 0.01% of the total.
The irq
xchg_relaxed(>cnts, _QW_WAITING,
+ atomic_cond_read_relaxed(>cnts, VAL == _QW_WAITING);
+ } while (atomic_cmpxchg_acquire(>cnts, _QW_WAITING,
_QW_LOCKED) != _QW_WAITING);
unlock:
arch_spin_unlock(>wait_lock);
Acked-by: Waiman Long
On 4/15/21 1:10 PM, Matthew Wilcox wrote:
On Tue, Apr 13, 2021 at 09:20:22PM -0400, Waiman Long wrote:
With memory accounting disable, the run time was 2.848s. With memory
accounting enabled, the run times with the application of various
patches in the patchset were:
Applied patches Run
On 4/15/21 12:50 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:25PM -0400, Waiman Long wrote:
Before the new slab memory controller with per object byte charging,
charging and vmstat data update happen only when new slab pages are
allocated or freed. Now they are done with every
On 4/15/21 12:40 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:23PM -0400, Waiman Long wrote:
The caller of mod_memcg_lruvec_state() has both memcg and lruvec readily
available. So both of them are now passed to mod_memcg_lruvec_state()
and __mod_memcg_lruvec_state
On 4/15/21 12:45 PM, Will Deacon wrote:
With that in mind, it would probably be a good idea to eyeball the qspinlock
slowpath as well, as that uses both atomic_cond_read_acquire() and
atomic_try_cmpxchg_relaxed().
It seems plausible that the same thing could occur here in qspinlock:
On 4/15/21 12:30 PM, Johannes Weiner wrote:
On Tue, Apr 13, 2021 at 09:20:24PM -0400, Waiman Long wrote:
In memcg_slab_free_hook()/pcpu_memcg_free_hook(), obj_cgroup_uncharge()
is followed by mod_objcg_state()/mod_memcg_state(). Each of these
function call goes through a separate irq_save
On 4/15/21 10:25 AM, Ali Saidi wrote:
While this code is executed with the wait_lock held, a reader can
acquire the lock without holding wait_lock. The writer side loops
checking the value with the atomic_cond_read_acquire(), but only truly
acquires the lock when the compare-and-exchange is
On 4/14/21 11:26 PM, Masayoshi Mizuma wrote:
Hi Longman,
Thank you for your patches.
I rerun the benchmark with your patches, it seems that the reduction
is small... The total duration of sendto() and recvfrom() system call
during the benchmark are as follows.
- sendto
- v5.8 vanilla:
On 4/14/21 1:26 PM, Andi Kleen wrote:
The CNA code, if enabled, will be in vmlinux, not in a kernel module. As a
result, I think a module parameter will be no different from a kernel
command line parameter in this regard.
You can still change it in /sys at runtime, even if it's in the vmlinux.
On 4/13/21 5:01 PM, Alex Kogan wrote:
Hi, Andi.
Thanks for your comments!
On Apr 13, 2021, at 2:03 AM, Andi Kleen wrote:
Alex Kogan writes:
+ numa_spinlock_threshold=[NUMA, PV_OPS]
+ Set the time threshold in milliseconds for the
+
The object stock data stored in struct memcg_stock_pcp are independent
of the other page based data stored there. Separating them out into
their own struct to highlight the independency.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
mm/memcontrol.c | 41
and not reflected in the charge counter and the vmstat
arrays. However, this is a small price to pay for better performance.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
mm/memcontrol.c | 74 +++--
1 file changed
.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/memcontrol.h | 12 +++-
mm/memcontrol.c| 19 +--
mm/slab.h | 2 +-
3 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/include/linux
,
the figure was about 16% (21894614 out of 139780628). So caching the
vmstat data reduces the number of calls to mod_objcg_state() by more
than 80%.
Signed-off-by: Waiman Long
Reviewed-by: Shakeel Butt
---
mm/memcontrol.c | 78 +++--
mm/slab.h
them with a single irq_save/irq_restore cycle.
Signed-off-by: Waiman Long
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
---
include/linux/memcontrol.h | 2 ++
mm/memcontrol.c| 31 +++
mm/percpu.c| 9 ++---
mm/slab.h
l.org/lkml/20210114025151.GA22932@xsang-OptiPlex-9020/
Waiman Long (5):
mm/memcg: Pass both memcg and lruvec to mod_memcg_lruvec_state()
mm/memcg: Introduce obj_cgroup_uncharge_mod_state()
mm/memcg: Cache vmstat data in percpu memcg_stock_pcp
mm/memcg: Separate out object stock data into its
On 4/12/21 7:10 PM, Shakeel Butt wrote:
On Mon, Apr 12, 2021 at 3:55 PM Waiman Long wrote:
Most kmem_cache_alloc() calls are from user context. With instrumentation
enabled, the measured amount of kmem_cache_alloc() calls from non-task
context was about 0.01% of the total.
The irq disable
as well which also helps.
[1] https://lore.kernel.org/linux-mm/20210408193948.vfktg3azh2wrt56t@gabell/T/#u
[2] https://lore.kernel.org/lkml/20210114025151.GA22932@xsang-OptiPlex-9020/
Waiman Long (5):
mm/memcg: Pass both memcg and lruvec to mod_memcg_lruvec_state()
mm/memcg: Introduce
.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/memcontrol.h | 12 +++-
mm/memcontrol.c| 19 +--
mm/slab.h | 2 +-
3 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/include/linux
The object stock data stored in struct memcg_stock_pcp are independent
of the other page based data stored there. Separating them out into
their own struct to highlight the independency.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
---
mm/memcontrol.c | 41
and not reflected in the charge counter and the vmstat
arrays. However, this is a small price to pay for better performance.
Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
---
mm/memcontrol.c | 73 +++--
1 file changed, 59 insertions(+), 14
them with a single irq_save/irq_restore cycle.
Signed-off-by: Waiman Long
Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
---
include/linux/memcontrol.h | 2 ++
mm/memcontrol.c| 31 +++
mm/percpu.c| 9 ++---
mm/slab.h
,
the figure was about 16% (21894614 out of 139780628). So caching the
vmstat data reduces the number of calls to mod_objcg_state() by more
than 80%.
Signed-off-by: Waiman Long
---
mm/memcontrol.c | 78 +++--
mm/slab.h | 26 +++--
2
On 4/12/21 2:55 PM, Roman Gushchin wrote:
On Fri, Apr 09, 2021 at 07:18:42PM -0400, Waiman Long wrote:
Most kmem_cache_alloc() calls are from user context. With instrumentation
enabled, the measured amount of kmem_cache_alloc() calls from non-task
context was about 0.01% of the total.
The irq
On 4/12/21 3:05 PM, Roman Gushchin wrote:
On Fri, Apr 09, 2021 at 07:18:37PM -0400, Waiman Long wrote:
With the recent introduction of the new slab memory controller, we
eliminate the need for having separate kmemcaches for each memory
cgroup and reduce overall kernel memory usage. However, we
On 4/12/21 2:22 PM, Roman Gushchin wrote:
On Fri, Apr 09, 2021 at 07:18:40PM -0400, Waiman Long wrote:
Before the new slab memory controller with per object byte charging,
charging and vmstat data update happen only when new slab pages are
allocated or freed. Now they are done with every
On 4/12/21 2:04 PM, Roman Gushchin wrote:
On Fri, Apr 09, 2021 at 07:18:38PM -0400, Waiman Long wrote:
The caller of mod_memcg_lruvec_state() has both memcg and lruvec readily
available. So both of them are now passed to mod_memcg_lruvec_state()
and __mod_memcg_lruvec_state
On 4/12/21 1:47 PM, Roman Gushchin wrote:
On Mon, Apr 12, 2021 at 10:03:13AM -0400, Waiman Long wrote:
On 4/9/21 9:51 PM, Roman Gushchin wrote:
On Fri, Apr 09, 2021 at 07:18:37PM -0400, Waiman Long wrote:
With the recent introduction of the new slab memory controller, we
eliminate the need
On 4/9/21 9:51 PM, Roman Gushchin wrote:
On Fri, Apr 09, 2021 at 07:18:37PM -0400, Waiman Long wrote:
With the recent introduction of the new slab memory controller, we
eliminate the need for having separate kmemcaches for each memory
cgroup and reduce overall kernel memory usage. However, we
and not reflected in the charge counter and the vmstat
arrays. However, this is a small price to pay for better performance.
Signed-off-by: Waiman Long
---
mm/memcontrol.c | 71 +++--
1 file changed, 57 insertions(+), 14 deletions(-)
diff --git a/mm
The object stock data stored in struct memcg_stock_pcp are independent
of the other page based data stored there. Separating them out into
their own struct to highlight the independency.
Signed-off-by: Waiman Long
---
mm/memcontrol.c | 41 ++---
1 file
,
the figure was about 16% (21894614 out of 139780628). So caching the
vmstat data reduces the number of calls to mod_objcg_state() by more
than 80%.
Signed-off-by: Waiman Long
---
mm/memcontrol.c | 78 +++--
mm/slab.h | 26 +++--
2
them with a single irq_save/irq_restore cycle.
Signed-off-by: Waiman Long
---
include/linux/memcontrol.h | 2 ++
mm/memcontrol.c| 31 +++
mm/percpu.c| 9 ++---
mm/slab.h | 6 +++---
4 files changed, 34 insertions
mod_memcg_lruvec_state() equivalent to mod_memcg_state() if lruvec
is null.
Signed-off-by: Waiman Long
---
include/linux/memcontrol.h | 12 +++-
mm/memcontrol.c| 19 +--
mm/slab.h | 2 +-
3 files changed, 21 insertions(+), 12 deletions(-)
diff --git
@gabell/T/#u
Waiman Long (5):
mm/memcg: Pass both memcg and lruvec to mod_memcg_lruvec_state()
mm/memcg: Introduce obj_cgroup_uncharge_mod_state()
mm/memcg: Cache vmstat data in percpu memcg_stock_pcp
mm/memcg: Separate out object stock data into its own struct
mm/memcg: Optimize user
On 4/6/21 7:52 PM, Stafford Horne wrote:
For OpenRISC I did ack the patch to convert to
CONFIG_ARCH_USE_QUEUED_SPINLOCKS_XCHG32=y. But I think you are right, the
generic code in xchg_tail and the xchg16 emulation code in produced by OpenRISC
using xchg32 would produce very similar code. I
On 4/6/21 5:15 AM, Peter Zijlstra wrote:
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
On 4/5/21 8:18 PM, Steven Rostedt wrote:
On Mon, 5 Apr 2021 19:42:03 -0400
Waiman Long wrote:
+/*
+ * All the print_cpu() callers from sched_debug_show() will be allowed
+ * to contend for sched_debug_lock and use group_path[] as their SEQ_printf()
+ * calls will be much faster. However only
onsole writer will have to use a shorter stack buffer instead. Since
the console output will be garbled anyway, truncation of some cgroup
paths shouldn't be a big issue.
Fixes: efe25c2c7b3a ("sched: Reinstate group names in /proc/sched_debug")
Signed-off-by: Waiman Long
---
kernel/sc
On 4/4/21 9:27 PM, Waiman Long wrote:
On 4/4/21 12:02 PM, Steven Rostedt wrote:
On Fri, 2 Apr 2021 23:09:09 -0400
Waiman Long wrote:
The main problem with sched_debug_lock is that under certain
circumstances, a lock waiter may wait a long time to acquire the lock
(in seconds). We can't
On 4/4/21 12:02 PM, Steven Rostedt wrote:
On Fri, 2 Apr 2021 23:09:09 -0400
Waiman Long wrote:
The main problem with sched_debug_lock is that under certain
circumstances, a lock waiter may wait a long time to acquire the lock
(in seconds). We can't insert touch_nmi_watchdog() while the cpu
On 4/2/21 4:40 PM, Steven Rostedt wrote:
On Thu, 1 Apr 2021 14:10:30 -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
until the printk rework is done so that printk() will take much
less time to execute than before.
Fixes: efe25c2c7b3a ("sched: Reinstate group names in /proc/sched_debug")
Signed-off-by: Waiman Long
---
kernel/sched/debug.c | 33 +
1 file changed, 25
On 3/30/21 6:42 AM, Daniel Thompson wrote:
On Mon, Mar 29, 2021 at 03:32:35PM -0400, Waiman Long wrote:
The handling of sysrq keys should normally be done in an user context
except when MAGIC_SYSRQ_SERIAL is set and the magic sequence is typed
in a serial console.
This seems to be a poor
On 3/29/21 11:13 PM, 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 =
CPU0 CPU1
= =
xchg16(ptr, new) while(1)
.
+
config LOCK_TORTURE_TEST
tristate "torture tests for locking"
depends on DEBUG_KERNEL
It looks good to me.
Acked-by: Waiman Long
On 3/29/21 8:42 AM, Thomas Gleixner wrote:
Waiman,
On Sun, Mar 28 2021 at 20:52, Waiman Long wrote:
It was found that the following circular locking dependency warning
could happen in some systems:
[ 218.097878] ==
[ 218.097879] WARNING
until after printk().
Fixes: efe25c2c7b3a ("sched: Reinstate group names in /proc/sched_debug")
Signed-off-by: Waiman Long
---
kernel/sched/debug.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/debug.c b/kernel/sch
On 3/29/21 6:23 AM, 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 are invoked by user action
oken due to vector space exhaustion.
To avoid this potential deadlock scenario, this patch moves all the
pr_warn() calls in the vector.c file out of the vector_lock critical
sections.
Signed-off-by: Waiman Long
---
arch/x86/kernel/apic/vector.c | 35 +--
1 fil
On 3/28/21 6:04 PM, Thomas Gleixner wrote:
Waiman,
On Sun, Mar 28 2021 at 15:58, Waiman Long wrote:
It was found that the following circular locking dependency warning
could happen in some systems:
[ 218.097878] ==
[ 218.097879] WARNING
oks that this warning message is relatively more common than
the other warnings in arch/x86/kernel/apic/vector.c. To avoid this
potential deadlock scenario, this patch moves all the pr_warn() calls
in the vector.c file outside of the vector_lock critical sections.
Signed-off-by: Waiman Long
---
arch/x86/ker
d. Fix that by not disabling IRQ when taking sched_debug_lock.
Fixes: efe25c2c7b3a ("sched: Reinstate group names in /proc/sched_debug")
Signed-off-by: Waiman Long
---
kernel/sched/debug.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/debug.c b/kernel/sch
() level will unnecessarily block the progress of other
print_cpu() users. Fix that by holding sched_debug_lock only when using
cgroup_path[] via task_group_path().
Signed-off-by: Waiman Long
---
kernel/sched/debug.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git
sed
* 16-17: tail index
* 18-31: tail cpu (+1)
The 9-15 bits are wasted to use xchg16 in xchg_tail.
Please let architecture select xchg16/xchg32 to implement
xchg_tail.
Signed-off-by: Guo Ren
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Ingo Molnar
Cc: Waiman Long
Cc: Arnd Bergmann
Cc: Anup Pa
On 3/22/21 9:09 PM, Shaokun Zhang wrote:
Commit 0cd39f4600ed ("locking/seqlock, headers: Untangle the spaghetti monster")
introduces 'struct ww_acquire_ctx' again, remove the repeated declaration.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Waiman Long
Cc: Boqun Feng
On 3/21/21 2:49 AM, Tetsuo Handa wrote:
Since this message is printed when dynamically allocated spinlocks (e.g.
kzalloc()) are used without initialization (e.g. spin_lock_init()),
suggest developers to check whether initialization functions for objects
are called, before making developers
On 3/19/21 7:16 AM, Ingo Molnar wrote:
* Waiman Long wrote:
This is a follow-up patch series for the previous patchset on fixing
locktorture ww_mutex test problem [1]. The first 3 patches of that
series were merged into tip. It turns out that the last one of the
three wasn't quite right. So
1 - 100 of 6450 matches
Mail list logo
