On Thu, 26 Feb 2015 14:47:54 +0100
Peter Zijlstra wrote:
> > Thinking about this more, is it because a wmb just forces the CPU to
> > write everything before this before it writes anything after it. That
> > is, the writes themselves can happen at a much later time. Does a plain
> > mb() work
On Thu, Feb 26, 2015 at 07:43:01AM -0500, Steven Rostedt wrote:
> On Thu, 26 Feb 2015 08:45:59 +0100
> Peter Zijlstra wrote:
>
> > On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
> > > It can't be used for state?
> > >
> > > If one CPU writes "zero", and the other CPU wants to
On Thu, 26 Feb 2015 08:49:07 +0100
Peter Zijlstra wrote:
> Yes, notice that we don't start iterating at the beginning; this in on
> purpose. If we start iterating at the beginning, _every_ cpu will again
> pile up on the first one.
>
> By starting at the current cpu, each cpu will start
On Thu, 26 Feb 2015 08:45:59 +0100
Peter Zijlstra wrote:
> On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
> > It can't be used for state?
> >
> > If one CPU writes "zero", and the other CPU wants to decide if the
> > system is in the state to do something, isn't a rmb() fine to
On Thu, 26 Feb 2015 08:49:07 +0100
Peter Zijlstra pet...@infradead.org wrote:
Yes, notice that we don't start iterating at the beginning; this in on
purpose. If we start iterating at the beginning, _every_ cpu will again
pile up on the first one.
By starting at the current cpu, each cpu
On Thu, 26 Feb 2015 14:47:54 +0100
Peter Zijlstra pet...@infradead.org wrote:
Thinking about this more, is it because a wmb just forces the CPU to
write everything before this before it writes anything after it. That
is, the writes themselves can happen at a much later time. Does a plain
On Thu, 26 Feb 2015 08:45:59 +0100
Peter Zijlstra pet...@infradead.org wrote:
On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
It can't be used for state?
If one CPU writes zero, and the other CPU wants to decide if the
system is in the state to do something, isn't a
On Thu, Feb 26, 2015 at 07:43:01AM -0500, Steven Rostedt wrote:
On Thu, 26 Feb 2015 08:45:59 +0100
Peter Zijlstra pet...@infradead.org wrote:
On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
It can't be used for state?
If one CPU writes zero, and the other CPU wants
On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
> > Well, the problem with it is one of collisions. So the 'easy' solution I
> > proposed would be something like:
> >
> > int ips_next(struct ipi_pull_struct *ips)
> > {
> > int cpu = ips->src_cpu;
> > cpu =
On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
> It can't be used for state?
>
> If one CPU writes "zero", and the other CPU wants to decide if the
> system is in the state to do something, isn't a rmb() fine to use?
>
>
> CPU 1:
>
> x = 0;
> /* Tell other CPUs
On Wed, 25 Feb 2015 18:11:10 +0100
Peter Zijlstra wrote:
>
> > Actually, this is a speed up, but if exiting a irq handler is also a
> > full barrier, then it is not needed.
>
> Barrieres are _NEVER_ about speedups, they're either required or not.
"speed up" was a wrong word. "correct state"
On Wed, Feb 25, 2015 at 06:11:10PM +0100, Peter Zijlstra wrote:
>
> #define IPS_BUSY 0x01
> #define IPS_LOOPED0x02
>
> struct ipi_pull_struct {
> struct irq_work work;
> raw_spinlock_t lock;
> int flags;
> int dst_cpu;/* CPU that issued this search */
>
On Wed, Feb 25, 2015 at 10:51:16AM -0500, Steven Rostedt wrote:
> > > +static void try_to_push_tasks(void *arg)
> > > +{
> > > + struct rt_rq *rt_rq = arg;
> > > + struct rq *rq, *next_rq;
> > > + int next_cpu = -1;
> > > + int next_prio = MAX_PRIO + 1;
> > > + int this_prio;
> > > + int src_prio;
On Wed, 25 Feb 2015 11:35:35 +0100
Peter Zijlstra wrote:
> On Tue, Feb 24, 2015 at 01:39:46PM -0500, Steven Rostedt wrote:
> > Index: linux-rt.git/kernel/sched/rt.c
> > ===
> > --- linux-rt.git.orig/kernel/sched/rt.c 2015-02-24
On Tue, Feb 24, 2015 at 01:39:46PM -0500, Steven Rostedt wrote:
> Index: linux-rt.git/kernel/sched/rt.c
> ===
> --- linux-rt.git.orig/kernel/sched/rt.c 2015-02-24 10:44:08.798785452
> -0500
> +++ linux-rt.git/kernel/sched/rt.c
On Wed, 25 Feb 2015 11:35:35 +0100
Peter Zijlstra pet...@infradead.org wrote:
On Tue, Feb 24, 2015 at 01:39:46PM -0500, Steven Rostedt wrote:
Index: linux-rt.git/kernel/sched/rt.c
===
--- linux-rt.git.orig/kernel/sched/rt.c
On Wed, 25 Feb 2015 18:11:10 +0100
Peter Zijlstra pet...@infradead.org wrote:
Actually, this is a speed up, but if exiting a irq handler is also a
full barrier, then it is not needed.
Barrieres are _NEVER_ about speedups, they're either required or not.
speed up was a wrong word.
On Wed, Feb 25, 2015 at 10:51:16AM -0500, Steven Rostedt wrote:
+static void try_to_push_tasks(void *arg)
+{
+ struct rt_rq *rt_rq = arg;
+ struct rq *rq, *next_rq;
+ int next_cpu = -1;
+ int next_prio = MAX_PRIO + 1;
+ int this_prio;
+ int src_prio;
+ int prio;
+ int
On Wed, Feb 25, 2015 at 06:11:10PM +0100, Peter Zijlstra wrote:
#define IPS_BUSY 0x01
#define IPS_LOOPED0x02
struct ipi_pull_struct {
struct irq_work work;
raw_spinlock_t lock;
int flags;
int dst_cpu;/* CPU that issued this search */
int
On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
It can't be used for state?
If one CPU writes zero, and the other CPU wants to decide if the
system is in the state to do something, isn't a rmb() fine to use?
CPU 1:
x = 0;
/* Tell other CPUs they can now do
On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
Well, the problem with it is one of collisions. So the 'easy' solution I
proposed would be something like:
int ips_next(struct ipi_pull_struct *ips)
{
int cpu = ips-src_cpu;
cpu = cpumask_next(cpu, rto_mask);
On Tue, Feb 24, 2015 at 01:39:46PM -0500, Steven Rostedt wrote:
Index: linux-rt.git/kernel/sched/rt.c
===
--- linux-rt.git.orig/kernel/sched/rt.c 2015-02-24 10:44:08.798785452
-0500
+++ linux-rt.git/kernel/sched/rt.c
> +static void try_to_push_tasks(void *arg)
> +{
> + struct rt_rq *rt_rq = arg;
> + struct rq *rq, *next_rq;
> + int next_cpu = -1;
> + int next_prio = MAX_PRIO + 1;
> + int this_prio;
> + int src_prio;
> + int prio;
> + int this_cpu;
> + int success;
> +
On Tue, 24 Feb 2015 13:39:46 -0500
Steven Rostedt wrote:
> @@ -1775,6 +1946,15 @@ static int pull_rt_task(struct rq *this_
>*/
> smp_rmb();
>
> + /* Use local just in case a feature is switched in the middle of this */
> + if ((use_ipi = sched_feat(RT_PUSH_IPI))) {
> +
On Tue, 24 Feb 2015 13:39:46 -0500
Steven Rostedt wrote:
> +static void tell_cpu_to_push(int cpu, struct rq *rq, int prio)
> +{
> + /* We should never be here if the IPI is already out. */
> + BUG_ON(rq->rt.push_csd_pending);
> +
> + rq->rt.push_csd_pending = 1;
> +
When debugging the latencies on a 40 core box, where we hit 300 to
500 microsecond latencies, I found there was a huge contention on the
runqueue locks.
Investigating it further, running ftrace, I found that it was due to
the pulling of RT tasks.
The test that was run was the following:
On Tue, 24 Feb 2015 13:39:46 -0500
Steven Rostedt rost...@goodmis.org wrote:
@@ -1775,6 +1946,15 @@ static int pull_rt_task(struct rq *this_
*/
smp_rmb();
+ /* Use local just in case a feature is switched in the middle of this */
+ if ((use_ipi =
When debugging the latencies on a 40 core box, where we hit 300 to
500 microsecond latencies, I found there was a huge contention on the
runqueue locks.
Investigating it further, running ftrace, I found that it was due to
the pulling of RT tasks.
The test that was run was the following:
On Tue, 24 Feb 2015 13:39:46 -0500
Steven Rostedt rost...@goodmis.org wrote:
+static void tell_cpu_to_push(int cpu, struct rq *rq, int prio)
+{
+ /* We should never be here if the IPI is already out. */
+ BUG_ON(rq-rt.push_csd_pending);
+
+ rq-rt.push_csd_pending = 1;
+
+static void try_to_push_tasks(void *arg)
+{
+ struct rt_rq *rt_rq = arg;
+ struct rq *rq, *next_rq;
+ int next_cpu = -1;
+ int next_prio = MAX_PRIO + 1;
+ int this_prio;
+ int src_prio;
+ int prio;
+ int this_cpu;
+ int success;
+ int cpu;
+
+
30 matches
Mail list logo
