On Tue, Dec 5, 2023 at 6:48 AM Alessandro Carminati (Red Hat)
wrote:
>
> In the kernel environment, situations frequently arise where identical
> names are shared among symbols within both the core image and modules.
> While this doesn't pose issues for the kernel's binary itself, it
>
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
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 Fri, Dec 29, 2023 at 11:51:34AM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Masami Hiramatsu reported a memory leak in register_ftrace_direct() where
> if the number of new entries are added is large enough to cause two
> allocations in the loop:
>
> for (i =
From: Ingo Molnar
> Sent: 30 December 2023 20:38
>
> * David Laight wrote:
>
> > bool osq_lock(struct optimistic_spin_queue *lock)
> > {
> > - struct optimistic_spin_node *node = this_cpu_ptr(_node);
> > + struct optimistic_spin_node *node = raw_cpu_read(osq_node.self);
> > struct
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 independent patches, with that
From: Waiman Long
> Sent: 30 December 2023 15:57
>
> 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
On Sat, 30 Dec 2023 at 12:41, Linus Torvalds
wrote:
>
> UNTESTED patch to just do the "this_cpu_write()" parts attached.
> Again, note how we do end up doing that this_cpu_ptr conversion later
> anyway, but at least it's off the critical path.
Also note that while 'this_cpu_ptr()' doesn't
On Fri, 29 Dec 2023 at 12: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
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 independent patches, with that
osq_wait_next() clarification split into two.
I also did the
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 much
From: Waiman Long
> Sent: 30 December 2023 03:20
>
> 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
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' field
* 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' field to 'struct optimistic_spin_node' that can be
> > read with
On Fri, 29 Dec 2023 11:51:34 -0500
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Masami Hiramatsu reported a memory leak in register_ftrace_direct() where
> if the number of new entries are added is large enough to cause two
> allocations in the loop:
>
> for (i = 0; i <
15 matches
Mail list logo
