n question it feels a little like we're breaking
> >abstractions if we bump the counter directly in get_slave_by_id.
>
> Agreed; I think a better way to fix this is to enable the slave
> array for balance-rr mode, and then use the array to find the right
> slave. This
On Sat, Dec 05, 2020 at 11:45:13AM -0800, Jakub Kicinski wrote:
> Thanks for the patch!
Kind words for my first attempt at this. Sorry for answering a bit late,
proton-bridge is not my best friend lately.
>
> Looking at the code in question it feels a little like we're breaking
> abstractions if w
et is to be
>> sent and the "normal" algorithm then continues with interface++ which
>> then hits that same interface again.
>>
>> This patch updates the resending algorithm to update the global counter
>> of the next interface to use.
>>
>> Exam
then continues with interface++ which
> then hits that same interface again.
>
> This patch updates the resending algorithm to update the global counter
> of the next interface to use.
>
> Example (prior to patch):
>
> Consider 6 x 100 Mbit/s interfaces in a rr bond. The norm
resending algorithm to update the global counter
of the next interface to use.
Example (prior to patch):
Consider 6 x 100 Mbit/s interfaces in a rr bond. The normal order of links
being used to send would look like:
1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 ...
If, for instance, interface 2 where unable t
..a39233cb4d72 100644
> --- a/sound/usb/quirks-table.h
> +++ b/sound/usb/quirks-table.h
> @@ -3530,7 +3530,61 @@ AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"),
> }
> }
> },
> -
> +{
> + /*
> + * PIONEER
@@ -3530,7 +3530,61 @@ AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"),
}
}
},
-
+{
+ /*
+ * PIONEER DJ DDJ-RR
+ * PCM is 6 channels out & 4 channels in @ 44.1 fixed
+*/
+ USB_DEVICE_VENDOR_SPEC(0x2b73, 0x000
gt; > > > > > whether the new instructions are available. Also, some day I would
> > > > > > like to change Linux to have the new behavior even if FSGSBASE
> > > > > > instructions are not available, and this will break rr agai
ike to change Linux to have the new behavior even if FSGSBASE
> > > > > instructions are not available, and this will break rr again. (The
> > > > > current !FSGSBASE behavior is an ugly optimization of dubious value.
> > > > > I would not go so far as t
> > I don’t like this at all. Your behavior really shouldn’t depend on
> > > > whether the new instructions are available. Also, some day I would
> > > > like to change Linux to have the new behavior even if FSGSBASE
> > > > instructions are not
r the new instructions are available. Also, some day I would
> > > like to change Linux to have the new behavior even if FSGSBASE
> > > instructions are not available, and this will break rr again. (The
> > > current !FSGSBASE behavior is an ugly optimization of dubious
ge Linux to have the new behavior even if FSGSBASE
> > instructions are not available, and this will break rr again. (The
> > current !FSGSBASE behavior is an ugly optimization of dubious value.
> > I would not go so far as to describe it as correct.)
>
> Ok.
>
> > I wo
ailable, and this will break rr again. (The
> current !FSGSBASE behavior is an ugly optimization of dubious value.
> I would not go so far as to describe it as correct.)
Ok.
> I would suggest you do one of the following things:
>
> 1. Use int $0x80 directly to load 32-bit regs
's obnoxious to ask Kyle and
>> Robert to parse the GDT, LDT, and selector just to emulate the
>> demented pre-5.9 ptrace() behavior.
>>
>> --Andy
>
> We've already addressed the main issue on rr's side[0]. The only
> outstanding issue is that if yo
On August 24, 2020 5:30:56 PM PDT, Andy Lutomirski wrote:
>On Mon, Aug 24, 2020 at 4:52 PM H. Peter Anvin wrote:
>>
>> On 2020-08-24 14:10, Andy Lutomirski wrote:
>> >
>> > PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor.
>> >
>> > PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS and upda
;
> --Andy
We've already addressed the main issue on rr's side[0]. The only
outstanding issue is that if you record a trace with 32 bit programs
on a pre-5.9 64 bit kernel and then try to replay it on 5.9 it won't
work. If you hit this case rr will print an error message telling yo
On Mon, Aug 24, 2020 at 4:52 PM H. Peter Anvin wrote:
>
> On 2020-08-24 14:10, Andy Lutomirski wrote:
> >
> > PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor.
> >
> > PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS and updates the base
> > accordingly.
> >
> > PTRACE_READ_SEGMENT_BASE: p
On 2020-08-24 14:10, Andy Lutomirski wrote:
>
> PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor.
>
> PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS and updates the base accordingly.
>
> PTRACE_READ_SEGMENT_BASE: pass in a segment selector, get a base out.
> You would use this to popula
On Sat, Aug 22, 2020 at 6:19 AM Andy Lutomirski wrote:
>
> We can give you a new ptrace operation to load the selector and deduce the
> base from the descriptor table if it would help.
Concretely, we could add one of these:
PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor.
PTRACE_SE
e Huey wrote:
> >>>
> >>> On the x86-64 5.9-rc1 TLS is completely broken in 32 bit tracees when
> >>> running under rr[0]. Booting the kernel with `nofsgsbase` fixes it and
> >>> I bisected to
> >>> https://git.kernel.org/pub/scm/linux/ker
> On Aug 21, 2020, at 2:33 PM, Kyle Huey wrote:
>
> On Fri, Aug 21, 2020 at 1:08 PM Bae, Chang Seok
> wrote:
>>
>>
>>>> On Aug 20, 2020, at 21:41, Kyle Huey wrote:
>>>
>>> On the x86-64 5.9-rc1 TLS is completely broken in 32 bit tr
> On Aug 21, 2020, at 14:32, Kyle Huey wrote:
>
> 40c45904f818c1f6555294ca27afc5fda4f09e68 added magic for a 32 bit
> tracer tracing a 32 bit tracee on a 64 bit kernel, but it looks like a
> 64 bit tracer tracing a 32 bit tracee on a 64 bit kernel *is* now
> expected to preserve the fs/gsbase v
On Fri, Aug 21, 2020 at 1:08 PM Bae, Chang Seok
wrote:
>
>
> > On Aug 20, 2020, at 21:41, Kyle Huey wrote:
> >
> > On the x86-64 5.9-rc1 TLS is completely broken in 32 bit tracees when
> > running under rr[0]. Booting the kernel with `nofsgsbase` fixes it an
> On Aug 20, 2020, at 21:41, Kyle Huey wrote:
>
> On the x86-64 5.9-rc1 TLS is completely broken in 32 bit tracees when
> running under rr[0]. Booting the kernel with `nofsgsbase` fixes it and
> I bisected to
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.
On the x86-64 5.9-rc1 TLS is completely broken in 32 bit tracees when
running under rr[0]. Booting the kernel with `nofsgsbase` fixes it and
I bisected to
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.8&id=673903495c85137791d5820d690229efe09c8f7b.
STR:
1. B
On Tue, Nov 27, 2018 at 03:36:15PM -0800, Andi Kleen wrote:
> > It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of
> > rather limited use (or even negative, in our case) to a counter that's
> > already restricted to ring 3.
>
> It's much faster. The PMI cost goes down dramatically.
aster. The PMI cost goes down dramatically.
I still the the right fix is to add an perf event opt-out and let it be
used by rr.
V3 is without counter freezing.
V4 is with counter freezing.
The value is the average cost of the PMI handler.
(lower is better)
pe
MI cost goes down dramatically.
>
> I still the the right fix is to add an perf event opt-out and let it be
> used by rr.
>
>V3 is without counter freezing.
> V4 is with counter freezing.
> The value is the average cost of the PMI handler.
> (lower is bet
opt-out and let it be
used by rr.
V3 is without counter freezing.
V4 is with counter freezing.
The value is the average cost of the PMI handler.
(lower is better)
perf options` V3(ns) V4(ns) delta
-c 10 1088 894 -1
On Wed, Nov 21, 2018 at 12:14 AM Peter Zijlstra wrote:
>
> On Tue, Nov 20, 2018 at 02:38:54PM -0800, Andi Kleen wrote:
> > > In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> > > independent counters, because while one counter overflows, we'll stall
> > > counting on all others unti
On Tue, Nov 20, 2018 at 02:38:54PM -0800, Andi Kleen wrote:
> > In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> > independent counters, because while one counter overflows, we'll stall
> > counting on all others until we've handled the PMI.
> >
> > Even though the PMI might not be
> In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> independent counters, because while one counter overflows, we'll stall
> counting on all others until we've handled the PMI.
>
> Even though the PMI might not be for them and they very much want/need
> to continue counting.
We sto
On Tue, Nov 20, 2018 at 11:16:42PM +0100, Peter Zijlstra wrote:
> Ooh, so the thing does FREEZE_ON_OVERFLOW _not_ FREEZE_ON_PMI. Yes, that
> can be a big difference.
>
> See, FREEZE_ON_PMI, as advertised by the name, should have no observable
> effect on counters limited to USR. But something like
r most usages it doesn't matter.
> >
> > I suspect that's a case for supporting opt-out for freezing
> > per perf event, and rr using that.
>
> I don't see how you could easily opt-out on a per perf event basis. If
> I'm reading the SDM correctly the F
On Tue, Nov 20, 2018 at 12:11:44PM -0800, Andi Kleen wrote:
> > > > Given that we're already at rc3, and that this renders rr unusable,
> > > > we'd ask that counter freezing be disabled for the 4.20 release.
> > >
> > > The boot option sho
vents between
> > the overflow itself and the transition to the PMI handler are
> > permanently lost) which is catastrophically bad for us :)
>
> Yes that's a fair point. For most usages it doesn't matter.
>
> I suspect that's a case for supporting opt-out for
On Tue, Nov 20, 2018 at 1:19 PM Stephane Eranian wrote:
>
> On Tue, Nov 20, 2018 at 12:53 PM Kyle Huey wrote:
> >
> > On Tue, Nov 20, 2018 at 12:11 PM Andi Kleen wrote:
> > >
> > > > > > Given that we're already at rc3, and that this rend
On Tue, Nov 20, 2018 at 12:53 PM Kyle Huey wrote:
>
> On Tue, Nov 20, 2018 at 12:11 PM Andi Kleen wrote:
> >
> > > > > Given that we're already at rc3, and that this renders rr unusable,
> > > > > we'd ask that counter freezing be disabled f
I handler are
> permanently lost) which is catastrophically bad for us :)
Yes that's a fair point. For most usages it doesn't matter.
I suspect that's a case for supporting opt-out for freezing
per perf event, and rr using that.
-Andi
On Tue, Nov 20, 2018 at 12:11 PM Andi Kleen wrote:
>
> > > > Given that we're already at rc3, and that this renders rr unusable,
> > > > we'd ask that counter freezing be disabled for the 4.20 release.
> > >
> > > The boot option should b
> > > Given that we're already at rc3, and that this renders rr unusable,
> > > we'd ask that counter freezing be disabled for the 4.20 release.
> >
> > The boot option should be good enough for the release?
>
> I'm not entirely sure what yo
On Tue, Nov 20, 2018 at 11:41 AM Andi Kleen wrote:
>
> > rr, a userspace record and replay debugger[0], uses the PMU interrupt
> > (PMI) to stop a program during replay to inject asynchronous events
> > such as signals. With perf counter freezing enabled we are reliably
nitial characterization of the problem as an overcount during
replay is incorrect; what we are actually seeing is an undercount
during recording.
rr relies on the userspace retired-conditional-branches counter being
exactly the same between recording and replay. The primary reason we
do this is to establish a p
> rr, a userspace record and replay debugger[0], uses the PMU interrupt
> (PMI) to stop a program during replay to inject asynchronous events
> such as signals. With perf counter freezing enabled we are reliably
> seeing perf event overcounts during replay. This behavior is easily
On Tue, Nov 20, 2018 at 9:08 AM Peter Zijlstra wrote:
>
> On Tue, Nov 20, 2018 at 08:19:39AM -0800, Kyle Huey wrote:
> > tl;dr: rr is currently broken on 4.20rc2, which I bisected to
> > af3bdb991a5cb57c189d34aadbd3aa88995e0d9f. I further confirmed that
> > booting
On Tue, Nov 20, 2018 at 08:19:39AM -0800, Kyle Huey wrote:
> tl;dr: rr is currently broken on 4.20rc2, which I bisected to
> af3bdb991a5cb57c189d34aadbd3aa88995e0d9f. I further confirmed that
> booting the 4.20rc2 kernel with `disable_counter_freezing=true` allows
> rr to work
tl;dr: rr is currently broken on 4.20rc2, which I bisected to
af3bdb991a5cb57c189d34aadbd3aa88995e0d9f. I further confirmed that
booting the 4.20rc2 kernel with `disable_counter_freezing=true` allows
rr to work.
rr, a userspace record and replay debugger[0], uses the PMU interrupt
(PMI) to stop a
On Thu, Jun 07, 2018 at 08:06:51AM -0700, Linus Torvalds wrote:
> On Thu, Jun 7, 2018 at 2:41 AM Paul E. McKenney
> wrote:
> >
> > We are considering adding unmarked accesses, for example, accesses
> > protected by locks. One possible litmus test (not yet supported!)
> > might look like this:
>
On Thu, Jun 7, 2018 at 7:57 AM Alan Stern wrote:
>
> You can look at a memory model from three points of view:
>
> 1. To a programmer, the model provides both guarantees (a certain
> code snippet will never yield a particular undesired result)
> and warnings (another snippet m
On Thu, Jun 7, 2018 at 2:41 AM Paul E. McKenney
wrote:
>
> We are considering adding unmarked accesses, for example, accesses
> protected by locks. One possible litmus test (not yet supported!)
> might look like this:
Fair enough - you do want to have the distinction between "marked" and
"unmark
On Thu, 7 Jun 2018, Paul E. McKenney wrote:
> On Wed, Jun 06, 2018 at 12:23:33PM -0700, Linus Torvalds wrote:
> > On Wed, Jun 6, 2018 at 12:05 PM Paul E. McKenney
> > wrote:
> > >
> > > 3. Introduce a new marking/attribute in the .def file that indicates
> > > whether an access is vo
On Wed, Jun 06, 2018 at 12:23:33PM -0700, Linus Torvalds wrote:
> On Wed, Jun 6, 2018 at 12:05 PM Paul E. McKenney
> wrote:
> >
> > 3. Introduce a new marking/attribute in the .def file that indicates
> > whether an access is volatile or implies a compiler barrier.
> > This mi
On Wed, Jun 6, 2018 at 12:05 PM Paul E. McKenney
wrote:
>
> 3. Introduce a new marking/attribute in the .def file that indicates
> whether an access is volatile or implies a compiler barrier.
> This might allow herd to be more selective about control dependencies,
> fo
On Wed, Jun 06, 2018 at 11:40:13AM +0200, Roman Penyaev wrote:
> On Wed, May 30, 2018 at 9:08 PM, Alan Stern wrote:
> > On Wed, 30 May 2018, Paul E. McKenney wrote:
> >
> >> On Wed, May 30, 2018 at 09:59:28AM -0500, Linus Torvalds wrote:
> >> > On Wed, May 30, 2018 at 9:29 AM Alan Stern
> >> > wr
On Wed, 6 Jun 2018, Roman Penyaev wrote:
> On Wed, Jun 6, 2018 at 3:54 PM, Alan Stern wrote:
> > On Wed, 6 Jun 2018, Roman Penyaev wrote:
> >
> >> > Preserving the order of volatile accesses isn't sufficient. The
> >> > compiler is still allowed to translate
> >> >
> >> > r1 = READ_ONCE(
On Wed, Jun 6, 2018 at 3:54 PM, Alan Stern wrote:
> On Wed, 6 Jun 2018, Roman Penyaev wrote:
>
>> > Preserving the order of volatile accesses isn't sufficient. The
>> > compiler is still allowed to translate
>> >
>> > r1 = READ_ONCE(x);
>> > if (r1) {
>> > ...
>> >
On Wed, 6 Jun 2018, Roman Penyaev wrote:
> > Preserving the order of volatile accesses isn't sufficient. The
> > compiler is still allowed to translate
> >
> > r1 = READ_ONCE(x);
> > if (r1) {
> > ...
> > }
> > WRITE_ONCE(y, r2);
> >
> > into someth
On Wed, May 30, 2018 at 9:08 PM, Alan Stern wrote:
> On Wed, 30 May 2018, Paul E. McKenney wrote:
>
>> On Wed, May 30, 2018 at 09:59:28AM -0500, Linus Torvalds wrote:
>> > On Wed, May 30, 2018 at 9:29 AM Alan Stern
>> > wrote:
>> >
>> > > >
>> > > > Can't we simplify the whole sequence as basical
On Mon, Jun 04, 2018 at 10:17:47AM -0400, Alan Stern wrote:
> On Sat, 2 Jun 2018, Paul E. McKenney wrote:
>
> > One crude but effective workaround is to replicate the code following the
> > "if" statement into both legs of the "if" statement. This has the effect
> > of extending the control depen
On Sat, 2 Jun 2018, Paul E. McKenney wrote:
> One crude but effective workaround is to replicate the code following the
> "if" statement into both legs of the "if" statement. This has the effect
> of extending the control dependency to cover all of the code that used to
> follow the "if" statemen
is has the effect
of extending the control dependency to cover all of the code that used to
follow the "if" statement, leveraging herd's current limited knowledge of
compiler optimization. This workaround would of course be hopeless for
general Linux-kernel code, but should be at least semi-a
On Wed, 30 May 2018, Paul E. McKenney wrote:
> On Wed, May 30, 2018 at 05:01:01PM -0500, Linus Torvalds wrote:
> > On Wed, May 30, 2018 at 2:08 PM Alan Stern
> > wrote:
> > >
> > > Indeed. The very first line Linus quoted in his first reply to me
> > > (elided above) was:
> > >
> > > Pu
On Wed, May 30, 2018 at 05:01:01PM -0500, Linus Torvalds wrote:
> On Wed, May 30, 2018 at 2:08 PM Alan Stern wrote:
> >
> > Indeed. The very first line Linus quoted in his first reply to me
> > (elided above) was:
> >
> > Putting this into herd would be extremely difficult, if not
> > im
On Wed, May 30, 2018 at 2:08 PM Alan Stern wrote:
>
> Indeed. The very first line Linus quoted in his first reply to me
> (elided above) was:
>
> Putting this into herd would be extremely difficult, if not
> impossible,
> because it involves analyzing code that was not executed.
On Wed, May 30, 2018 at 04:28:56PM -0400, Alan Stern wrote:
> On Wed, 30 May 2018, Paul E. McKenney wrote:
>
> > > > My current guess is that we need to change the memory-model tool. If
> > > > that is the case, here are some possible resolutions:
> > > >
> > > > 1. Make herd's C-language c
On Wed, 30 May 2018, Paul E. McKenney wrote:
> > > My current guess is that we need to change the memory-model tool. If
> > > that is the case, here are some possible resolutions:
> > >
> > > 1.Make herd's C-language control dependencies work the same as its
> > > assembly language, so
On Wed, May 30, 2018 at 03:08:43PM -0400, Alan Stern wrote:
> On Wed, 30 May 2018, Paul E. McKenney wrote:
>
> > On Wed, May 30, 2018 at 09:59:28AM -0500, Linus Torvalds wrote:
> > > On Wed, May 30, 2018 at 9:29 AM Alan Stern
> > > wrote:
> > >
> > > > >
> > > > > Can't we simplify the whole seq
On Wed, 30 May 2018, Paul E. McKenney wrote:
> On Wed, May 30, 2018 at 09:59:28AM -0500, Linus Torvalds wrote:
> > On Wed, May 30, 2018 at 9:29 AM Alan Stern
> > wrote:
> >
> > > >
> > > > Can't we simplify the whole sequence as basically
> > > >
> > > > A
> > > > if (!B)
> > > >
On Wed, May 30, 2018 at 09:59:28AM -0500, Linus Torvalds wrote:
> On Wed, May 30, 2018 at 9:29 AM Alan Stern
> wrote:
>
> > >
> > > Can't we simplify the whole sequence as basically
> > >
> > > A
> > > if (!B)
> > > D
> > >
> > > for that "not B" case, and just think about that
On Wed, 30 May 2018, Linus Torvalds wrote:
> On Wed, May 30, 2018 at 9:29 AM Alan Stern
> wrote:
>
> > >
> > > Can't we simplify the whole sequence as basically
> > >
> > > A
> > > if (!B)
> > > D
> > >
> > > for that "not B" case, and just think about that. IOW, let's ignore
On Wed, May 30, 2018 at 9:29 AM Alan Stern
wrote:
> >
> > Can't we simplify the whole sequence as basically
> >
> > A
> > if (!B)
> > D
> >
> > for that "not B" case, and just think about that. IOW, let's ignore the
> > whole "not executed" code.
> Your listing is slightly mis
On Tue, 29 May 2018, Paul E. McKenney wrote:
> On Tue, May 29, 2018 at 04:10:02PM -0500, Linus Torvalds wrote:
> > On Tue, May 29, 2018 at 3:49 PM Alan Stern
> > wrote:
> >
> > > Putting this into herd would be extremely difficult, if not impossible,
> > > because it involves analyzing code that
On Tue, 29 May 2018, Linus Torvalds wrote:
> On Tue, May 29, 2018 at 3:49 PM Alan Stern
> wrote:
>
> > Putting this into herd would be extremely difficult, if not impossible,
> > because it involves analyzing code that was not executed.
>
> Does it?
>
> Can't we simplify the whole sequence as
On Tue, May 29, 2018 at 04:10:02PM -0500, Linus Torvalds wrote:
> On Tue, May 29, 2018 at 3:49 PM Alan Stern
> wrote:
>
> > Putting this into herd would be extremely difficult, if not impossible,
> > because it involves analyzing code that was not executed.
One (ugly) way to handle it, assuming
On Tue, May 29, 2018 at 3:49 PM Alan Stern
wrote:
> Putting this into herd would be extremely difficult, if not impossible,
> because it involves analyzing code that was not executed.
Does it?
Can't we simplify the whole sequence as basically
A
if (!B)
D
for that "not B" ca
On Tue, 29 May 2018, Paul E. McKenney wrote:
> On Tue, May 29, 2018 at 02:35:34PM -0400, Alan Stern wrote:
> > On Mon, 28 May 2018, Paul E. McKenney wrote:
> >
> > > Hello!
> > >
> > > The litmus test below is a first attempt to model Roman's rcu
On Tue, May 29, 2018 at 02:35:34PM -0400, Alan Stern wrote:
> On Mon, 28 May 2018, Paul E. McKenney wrote:
>
> > Hello!
> >
> > The litmus test below is a first attempt to model Roman's rcu-rr
> > round-robin RCU-protected linked list. His test code, which in
On Mon, 28 May 2018, Paul E. McKenney wrote:
> Hello!
>
> The litmus test below is a first attempt to model Roman's rcu-rr
> round-robin RCU-protected linked list. His test code, which includes
> the algorithm under test, may be found here:
>
> https://github.com/roum
Hello!
The litmus test below is a first attempt to model Roman's rcu-rr
round-robin RCU-protected linked list. His test code, which includes
the algorithm under test, may be found here:
https://github.com/rouming/rcu-rr/blob/master/rcu-rr.c
The P0() process below roughly correspon
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vadim Lomovtsev
commit 7f342678634f16795892677204366e835e450dda upstream.
The Cavium ThunderX (CN8XXX) family of PCIe Root Ports does not advertise
an ACS capability. However, the RTL internal
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Vadim Lomovtsev
commit 7f342678634f16795892677204366e835e450dda upstream.
The Cavium ThunderX (CN8XXX) family of PCIe Root Ports does not advertise
an ACS capability. However, the RTL interna
On Wed, Oct 25, 2017 at 03:26:43PM -0700, Allen Martin wrote:
This is a _really_ ugly patch.
On Wed, 2017-10-25 at 15:26 -0700, Allen Martin wrote:
> Defer calling put_prev_task() on a CFS task_struct when there is a
> pending RT task to run. Instead wait until the next
> pick_next_task_fair() and do the work there.
Which donates execution time of the rt class task to the fair class
task
Defer calling put_prev_task() on a CFS task_struct when there is a
pending RT task to run. Instead wait until the next
pick_next_task_fair() and do the work there.
The put_prev_task() call for a SCHED_OTHER task is currently a source
of non determinism in the latency of scheduling a SCHED_FIFO ta
From: Vadim Lomovtsev
The Cavium ThunderX (CN8XXX) family PCIe Root Ports has limited PCI
capabilities in terms of no ACS support advertisement. However,
the RTL internally implements similar protection as if ACS had
completion/request redirection, upstream forwarding and validation
features enab
On Mon, Jan 23, 2017 at 03:26:09PM +0530, Chaitra P B wrote:
> Due existence of loop in the IO path our HBA will receive heavy IOs and
> also as driver is not updating the Reply Post Host Index frequently, So
> there will be a high chance that our Firmware unable to find any free entry
> in the Rep
Due existence of loop in the IO path our HBA will receive heavy IOs and
also as driver is not updating the Reply Post Host Index frequently, So
there will be a high chance that our Firmware unable to find any free entry
in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
observe
On Fri, Jan 20, 2017 at 8:40 PM, Johannes Thumshirn wrote:
> On Fri, Jan 20, 2017 at 08:12:12PM +0530, Chaitra P B wrote:
>> Due existence of loop in the IO path our HBA will receive heavy IOs and
>> also as driver is not updating the Reply Post Host Index frequently, So
>> there will be a high ch
On Fri, Jan 20, 2017 at 08:12:12PM +0530, Chaitra P B wrote:
> Due existence of loop in the IO path our HBA will receive heavy IOs and
> also as driver is not updating the Reply Post Host Index frequently, So
> there will be a high chance that our Firmware unable to find any free entry
> in the Rep
Due existence of loop in the IO path our HBA will receive heavy IOs and
also as driver is not updating the Reply Post Host Index frequently, So
there will be a high chance that our Firmware unable to find any free entry
in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
observe
Due existence of loop in the IO path our HBA will receive heavy IOs and
also as driver is not updating the Reply Post Host Index frequently, So
there will be a high chance that our Firmware unable to find any free entry
in the Reply Post Descriptor Queue (i.e. Queue overflow occurs) and can
observe
used later to fill in the RR
field of the batadv_icmp_packet_rr packet.
Instead re-evaluate eth_hdr after the skb_linearize+skb_cow to fix the
pointer and avoid the invalid read.
Fixes: da6b8c20a5b8 ("batman-adv: generalize batman-adv icmp packet handling")
Signed-off-by: Sven Eckelma
In order to evaluate the scheduler tick dependency without probing
context switches, we need to know how much SCHED_RR and SCHED_FIFO tasks
are enqueued as those policies don't have the same preemption
requirements.
To prepare for that, let's account SCHED_RR tasks, we'll be able to
deduce SCHED_F
In order to evaluate the scheduler tick dependency without probing
context switches, we need to know how much SCHED_RR and SCHED_FIFO tasks
are enqueued as those policies don't have the same preemption
requirements.
To prepare for that, let's account SCHED_RR tasks, we'll be able to
deduce SCHED_F
On Wed, Dec 02, 2015 at 01:53:39PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2015 at 03:22:06PM +0100, Frederic Weisbecker wrote:
> > In order to evaluate tick dependency, we need to account SCHED_RR and
> > SCHED_FIFO tasks separately as those policies don't have the same
> > preemption requi
On Fri, Nov 13, 2015 at 03:22:06PM +0100, Frederic Weisbecker wrote:
> In order to evaluate tick dependency, we need to account SCHED_RR and
> SCHED_FIFO tasks separately as those policies don't have the same
> preemption requirements.
>
> We still keep rt_nr_running as a cache to avoid additions
In order to evaluate tick dependency, we need to account SCHED_RR and
SCHED_FIFO tasks separately as those policies don't have the same
preemption requirements.
We still keep rt_nr_running as a cache to avoid additions between nr_rr
and nr_fifo all over the place.
Cc: Christoph Lameter
Cc: Chris
Hi Rusty,
After merging the rr-fixes tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/net/ethernet/mellanox/mlx4/en_tx.c: In function
'mlx4_en_create_tx_ring':
drivers/net/ethernet/mellanox/mlx4/en_tx.c:147:3: error: implicit declarati
The makefiles under tools/testing/selftests are not real kbuild
makefiles, they are regular stand alone makefiles. As such they *do*
want all the standard implicit rules and variables defined.
So before calling those makefiles, filter -rR out of MAKEFLAGS.
Without this not all the selftests are
nd alone makefiles. As such they *do*
> >>>>>> want all the standard implicit rules and variables defined.
> >>>>>>
> >>>>>> So before calling those makefiles, filter -rR out of MAKEFLAGS.
> >>>>>>
1 - 100 of 162 matches
Mail list logo
