On Mon, 2016-02-08 at 14:04 -0500, Tianyang Chen wrote:
>
> On 2/8/2016 6:27 AM, Dario Faggioli wrote:
> >
> > I don't really follow, but I have the feeling that you're making it
> > sound more complicated like it is in reality... :-)
> >
>
> So my reasoning is that, when sleep() is called in s
On 2/8/2016 6:27 AM, Dario Faggioli wrote:
On Fri, 2016-02-05 at 23:27 -0500, Tianyang Chen wrote:
On 2/5/2016 9:39 AM, Dario Faggioli wrote:
On Wed, 2016-02-03 at 21:23 -0500, Tianyang Chen wrote:
I see. So I'm just curious what can cause spurious wakeup? Does it
only
happen to a running
On Fri, 2016-02-05 at 23:27 -0500, Tianyang Chen wrote:
>
> On 2/5/2016 9:39 AM, Dario Faggioli wrote:
> > On Wed, 2016-02-03 at 21:23 -0500, Tianyang Chen wrote:
> > >
> I see. So I'm just curious what can cause spurious wakeup? Does it
> only
> happen to a running vcpu (currently on pcpu), and
On 2/5/2016 9:39 AM, Dario Faggioli wrote:
On Wed, 2016-02-03 at 21:23 -0500, Tianyang Chen wrote:
On 2/3/2016 7:39 AM, Dario Faggioli wrote:
On Tue, 2016-02-02 at 13:09 -0500, Tianyang Chen wrote:
So what do we do, we raise the *_delayed_runq_add flag and continue
and
leave the vcpu alon
On Wed, 2016-02-03 at 23:03 -0500, Meng Xu wrote:
> On Wed, Feb 3, 2016 at 7:39 AM, Dario Faggioli
> wrote:
> >
> > And, at this point, I'm starting thinking again that we want to
> > call
> > runq_tickle() in rt_context_saved(), at least in case
> > __RTDS_delayed_runq_add was set as, if we don'
On Wed, 2016-02-03 at 21:23 -0500, Tianyang Chen wrote:
>
> On 2/3/2016 7:39 AM, Dario Faggioli wrote:
> > On Tue, 2016-02-02 at 13:09 -0500, Tianyang Chen wrote:
> > >
> > So what do we do, we raise the *_delayed_runq_add flag and continue
> > and
> > leave the vcpu alone. This happens, for inst
On Wed, Feb 3, 2016 at 7:39 AM, Dario Faggioli
wrote:
>
> On Tue, 2016-02-02 at 13:09 -0500, Tianyang Chen wrote:
> > On 2/2/2016 10:08 AM, Dario Faggioli wrote:
> > > On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
> > > >
> > > > +struct rt_private *prv = rt_priv(ops);
> > > > +s
On 2/3/2016 7:39 AM, Dario Faggioli wrote:
On Tue, 2016-02-02 at 13:09 -0500, Tianyang Chen wrote:
On 2/2/2016 10:08 AM, Dario Faggioli wrote:
On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
+struct rt_private *prv = rt_priv(ops);
+struct list_head *replq = rt_replq(ops);
+
On Tue, 2016-02-02 at 13:09 -0500, Tianyang Chen wrote:
> On 2/2/2016 10:08 AM, Dario Faggioli wrote:
> > On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
> > >
> > > +struct rt_private *prv = rt_priv(ops);
> > > +struct list_head *replq = rt_replq(ops);
> > > +struct list_head
On Tue, 2016-02-02 at 22:33 -0500, Meng Xu wrote:
> On Tue, Feb 2, 2016 at 10:08 AM, Dario Faggioli
> wrote:
> >
> > Is it ok to kill the replenishment in this case?
> >
> > This is a genuine question. What does the dynamic DS algorithm that
> > you're trying to implement here says about this? M
Hi Dario and Tianyang,
I will just comment on the parts Tianyang hasn't replied.
On Tue, Feb 2, 2016 at 10:08 AM, Dario Faggioli
wrote:
>
> On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
> > v4 is meant for discussion on the addition of replq.
> >
> In which cases, you should always put
On 2/2/2016 10:08 AM, Dario Faggioli wrote:
On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
v4 is meant for discussion on the addition of replq.
In which cases, you should always put something like RFC in the
subject, so people knows what the intent is even by just skimming their
inb
On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
> v4 is meant for discussion on the addition of replq.
>
In which cases, you should always put something like RFC in the
subject, so people knows what the intent is even by just skimming their
inboxes.
> Changes since v3:
> removed run
v4 is meant for discussion on the addition of replq.
Changes since v3:
removed running queue.
added repl queue to keep track of repl events.
timer is now per scheduler.
timer is init on a valid cpu in a cpupool.
Bugs to be fixed: Cpupool and locks. When a pcpu is r
14 matches
Mail list logo
