...
> My guess is that *most* 32-bit architectures do not have a 64-bit
> cmpxchg - not even the irq-safe one.
Does any sparc32 even have a 32-bit cmpxchg?
The original versions (which were definitely SMP capable)
only had a byte sized atomic exchange that always wrote 0xff.
Sparc32 does have 'lo
On Thu, 14 Dec 2023 12:50:29 -0800
Linus Torvalds wrote:
> > But do all archs have an implementation of cmpxchg64, even if it requires
> > disabling interrupts? If not, then I definitely cannot remove this code.
>
> We have a generic header file, so anybody who uses that would get the
> fallba
On Thu, 14 Dec 2023 at 12:35, Steven Rostedt wrote:
>
> On Thu, 14 Dec 2023 11:44:55 -0800
> Linus Torvalds wrote:
>
> > On Thu, 14 Dec 2023 at 08:55, Steven Rostedt wrote:
> > >
> > > And yes, this does get called in NMI context.
> >
> > Not on an i486-class machine they won't. You don't have a
On Thu, 14 Dec 2023 11:44:55 -0800
Linus Torvalds wrote:
> On Thu, 14 Dec 2023 at 08:55, Steven Rostedt wrote:
> >
> > And yes, this does get called in NMI context.
>
> Not on an i486-class machine they won't. You don't have a local apic
> on those, and they won't have any NMI sources under o
On Thu, 14 Dec 2023 at 08:55, Steven Rostedt wrote:
>
> And yes, this does get called in NMI context.
Not on an i486-class machine they won't. You don't have a local apic
on those, and they won't have any NMI sources under our control (ie
NMI does exist, but we're talking purely legacy NMI for "m
On Wed, 13 Dec 2023 22:53:19 -0800
Linus Torvalds wrote:
> On Wed, 13 Dec 2023 at 18:45, Steven Rostedt wrote:
> >
> > tl;dr; The ring-buffer timestamp requires a 64-bit cmpxchg to keep the
> > timestamps in sync (only in the slow paths). I was told that 64-bit cmpxchg
> > can be extremely slow
On Wed, 13 Dec 2023 at 18:45, Steven Rostedt wrote:
>
> tl;dr; The ring-buffer timestamp requires a 64-bit cmpxchg to keep the
> timestamps in sync (only in the slow paths). I was told that 64-bit cmpxchg
> can be extremely slow on 32-bit architectures. So I created a rb_time_t
> that on 64-bit w
On 2023-12-13 21:11, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Each event has a 27 bit timestamp delta that is used to hold the delta
from the last event. If the time between events is greater than 2^27, then
a timestamp is added that holds a 59 bit absolute timestamp.
Until a389d8
On Wed, 13 Dec 2023 21:11:26 -0500
Steven Rostedt wrote:
> @@ -3720,6 +3517,7 @@ rb_reserve_next_event(struct trace_buffer *buffer,
> struct rb_event_info info;
> int nr_loops = 0;
> int add_ts_default;
> + static int once;
>
> /* ring buffer does cmpxchg, make sure
Linus,
Looking for some advice on this.
tl;dr; The ring-buffer timestamp requires a 64-bit cmpxchg to keep the
timestamps in sync (only in the slow paths). I was told that 64-bit cmpxchg
can be extremely slow on 32-bit architectures. So I created a rb_time_t
that on 64-bit was a normal local64_t
10 matches
Mail list logo
