On Tue, 19 May 2015, Steven Rostedt wrote:
> On Tue, 19 May 2015 10:35:32 -0500 (CDT)
> Christoph Lameter wrote:
>
> > On Thu, 19 Mar 2015, Steven Rostedt wrote:
> >
> > > On Thu, 19 Mar 2015 15:16:25 -0700
> > > Linus Torvalds wrote:
> > >
> > > > So I don't think the ring-buffer change is nece
On Tue, 19 May 2015 10:35:32 -0500 (CDT)
Christoph Lameter wrote:
> On Thu, 19 Mar 2015, Steven Rostedt wrote:
>
> > On Thu, 19 Mar 2015 15:16:25 -0700
> > Linus Torvalds wrote:
> >
> > > So I don't think the ring-buffer change is necessarily _wrong_, but if
> > > this is a performance issue, w
On Thu, 19 Mar 2015, Steven Rostedt wrote:
> On Thu, 19 Mar 2015 15:16:25 -0700
> Linus Torvalds wrote:
>
> > So I don't think the ring-buffer change is necessarily _wrong_, but if
> > this is a performance issue, why don't we just fix it up for the
> > generic case rather than for just one user?
On Mon, 18 May 2015 12:50:43 -0700
Linus Torvalds wrote:
> On Thu, Mar 19, 2015 at 3:16 PM, Linus Torvalds
> wrote:
> >
> > So I don't think the ring-buffer change is necessarily _wrong_, but if
> > this is a performance issue, why don't we just fix it up for the
> > generic case rather than for
On Thu, Mar 19, 2015 at 3:16 PM, Linus Torvalds
wrote:
>
> So I don't think the ring-buffer change is necessarily _wrong_, but if
> this is a performance issue, why don't we just fix it up for the
> generic case rather than for just one user?
This this_cpu_generic_read/this_cpu_generic_write() pe
Here is a potential patch for this.
Subject: [percpu] make this_cpu_read/write operate like raw_cpu_read/write
As noted threre is not much of a point in disabling preemption or interrupts
for this_cpu_read/write since the processor may change afterwards anyways
if preemption is on. Thus we should
On Mon, 23 Mar 2015, Steven Rostedt wrote:
> Any comment on this?
Yes we could do this but I am traveling a bit right now. Sorry not that
responsive.
It will not be strictly correct since a fetch or write could occur from a
different cpu and thereby kick out a cacheline. But that is minor I thin
Christoph,
Any comment on this?
-- Steve
On Thu, 19 Mar 2015 15:16:25 -0700
Linus Torvalds wrote:
> Ugh.
>
> I think this is bogus.
>
> Why?
>
> On Thu, Mar 19, 2015 at 3:02 PM, Steven Rostedt wrote:
> >
> > The generic version of this_cpu_read() and write() are:
> >
> > #define
On Fri, 20 Mar 2015 08:26:33 +0100
Uwe Kleine-König wrote:
> Hello Steven,
>
> On Thu, Mar 19, 2015 at 06:02:16PM -0400, Steven Rostedt wrote:
> > Reported-by: Uwe Kleine-KÃ=B6nig
> > Tested-by: Uwe Kleine-KÃ=B6nig
> Would you please care to type my name correctly? I just checked, the
Hello Steven,
On Thu, Mar 19, 2015 at 06:02:16PM -0400, Steven Rostedt wrote:
> Reported-by: Uwe Kleine-KÃ=B6nig
> Tested-by: Uwe Kleine-KÃ=B6nig
Would you please care to type my name correctly? I just checked, the git
commit is wrong, too.
Best regards
Uwe
--
Pengutronix e.K.
On Thu, 19 Mar 2015 18:34:44 -0400
Steven Rostedt wrote:
> On Thu, 19 Mar 2015 15:16:25 -0700
> Linus Torvalds wrote:
>
> > So I don't think the ring-buffer change is necessarily _wrong_, but if
> > this is a performance issue, why don't we just fix it up for the
> > generic case rather than fo
On Thu, 19 Mar 2015 15:16:25 -0700
Linus Torvalds wrote:
> So I don't think the ring-buffer change is necessarily _wrong_, but if
> this is a performance issue, why don't we just fix it up for the
> generic case rather than for just one user?
I totally agree with your analysis, but it's up to Ch
Ugh.
I think this is bogus.
Why?
On Thu, Mar 19, 2015 at 3:02 PM, Steven Rostedt wrote:
>
> The generic version of this_cpu_read() and write() are:
>
> #define this_cpu_generic_read(pcp) \
> ({ typeof(pcp) ret__;
Linus,
The recursion code in the internals of the ftrace ring buffer requires
using "preempt_disable_notrace". But it has been discovered that
preempt_disable() is being used by this_cpu_read() in some architectures
and trace_cpu_read() is part of the recursion protection of the ring buffer.
The
14 matches
Mail list logo
