On 2018-03-12 15:29:33 [+0100], Peter Zijlstra wrote:
> On Mon, Mar 12, 2018 at 03:11:07PM +0100, Sebastian Andrzej Siewior wrote:
> > I assumed you complained about the unbounded list-walk with interrupts
> > disabled (which is cheap but unbound is unbound). So here I suggested I
> > move 20 entri
On Mon, Mar 12, 2018 at 03:11:07PM +0100, Sebastian Andrzej Siewior wrote:
> I assumed you complained about the unbounded list-walk with interrupts
> disabled (which is cheap but unbound is unbound). So here I suggested I
> move 20 entries off that list a time and enable interrupts again so an
> in
On 2018-03-12 14:27:29 [+0100], Peter Zijlstra wrote:
> On Mon, Mar 12, 2018 at 11:51:13AM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-03-09 23:26:43 [+0100], Peter Zijlstra wrote:
> > > On Fri, Mar 09, 2018 at 09:25:50PM +0100, Sebastian Andrzej Siewior wrote:
> > > > Is it just about the
On Mon, Mar 12, 2018 at 11:51:13AM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-03-09 23:26:43 [+0100], Peter Zijlstra wrote:
> > On Fri, Mar 09, 2018 at 09:25:50PM +0100, Sebastian Andrzej Siewior wrote:
> > > Is it just about the irqsave() usage or something else? I doubt it is
> > > the lis
On 2018-03-09 23:26:43 [+0100], Peter Zijlstra wrote:
> On Fri, Mar 09, 2018 at 09:25:50PM +0100, Sebastian Andrzej Siewior wrote:
> > Is it just about the irqsave() usage or something else? I doubt it is
> > the list walk. It is still unbound if not called from irq-off region.
>
> The current lis
On Fri, Mar 09, 2018 at 09:25:50PM +0100, Sebastian Andrzej Siewior wrote:
> Is it just about the irqsave() usage or something else? I doubt it is
> the list walk. It is still unbound if not called from irq-off region.
The current list walk is preemptible. You put the entire iteration (of
unbound
On 03/09/2018 11:46 AM, Peter Zijlstra wrote:
On Fri, Mar 09, 2018 at 12:04:18PM +0100, Sebastian Andrzej Siewior wrote:
+void swake_add_all_wq(struct swait_queue_head *q, struct wake_q_head *wq)
{
struct swait_queue *curr;
while (!list_empty(&q->task_list)) {
curr = list_
On 2018-03-09 18:46:05 [+0100], Peter Zijlstra wrote:
> On Fri, Mar 09, 2018 at 12:04:18PM +0100, Sebastian Andrzej Siewior wrote:
> > +void swake_add_all_wq(struct swait_queue_head *q, struct wake_q_head *wq)
> > {
> > struct swait_queue *curr;
> >
> > while (!list_empty(&q->task_list))
On Fri, Mar 09, 2018 at 12:04:18PM +0100, Sebastian Andrzej Siewior wrote:
> +void swake_add_all_wq(struct swait_queue_head *q, struct wake_q_head *wq)
> {
> struct swait_queue *curr;
>
> while (!list_empty(&q->task_list)) {
>
> curr = list_first_entry(&q->task_list,
On 03/09/2018 08:58 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-09 07:29:31 [-0600], Corey Minyard wrote:
From what I can tell, wake_up_q() is unbounded, and you have undone what
the previous code had tried to accomplish. In the scenario I'm talking
about,
interrupts are still disabled her
On 2018-03-09 07:29:31 [-0600], Corey Minyard wrote:
> From what I can tell, wake_up_q() is unbounded, and you have undone what
> the previous code had tried to accomplish. In the scenario I'm talking
> about,
> interrupts are still disabled here. That's why I was asking about where to
> put
> wa
On 03/09/2018 05:04 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-08 13:54:17 [-0600], Corey Minyard wrote:
It will work but I don't think pushing this into workqueue/tasklet is a
good idea. You want to wakeup all waiters on waitqueue X (probably one
waiter) and instead there is one one wakeup
On 2018-03-08 13:54:17 [-0600], Corey Minyard wrote:
> > It will work but I don't think pushing this into workqueue/tasklet is a
> > good idea. You want to wakeup all waiters on waitqueue X (probably one
> > waiter) and instead there is one one wakeup + ctx-switch which does the
> > final wakeup.
>
On 03/08/2018 11:41 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-07 09:45:29 [-0600], Corey Minyard wrote:
I have no idea what is the wisest thing to do here. The obvious fix
would be to use the irqsafe() variant here and not drop the lock between
wake ups. That is essentially what swake_up_a
On 2018-03-07 09:45:29 [-0600], Corey Minyard wrote:
> > I have no idea what is the wisest thing to do here. The obvious fix
> > would be to use the irqsafe() variant here and not drop the lock between
> > wake ups. That is essentially what swake_up_all_locked() does which I
> > need for the comple
On 03/06/2018 11:46 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-05 09:08:11 [-0600], Corey Minyard wrote:
Starting with the change
8a64547a07980f9d25e962a78c2e10ee82bdb742 fs/dcache: use swait_queue instead
of
waitqueue
…
The following change is the obvious reason:
--- a/kernel/sched/swa
On 03/06/2018 11:46 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-05 09:08:11 [-0600], Corey Minyard wrote:
Starting with the change
8a64547a07980f9d25e962a78c2e10ee82bdb742 fs/dcache: use swait_queue instead
of
waitqueue
…
The following change is the obvious reason:
--- a/kernel/sched/swa
On 2018-03-05 09:08:11 [-0600], Corey Minyard wrote:
> Starting with the change
>
> 8a64547a07980f9d25e962a78c2e10ee82bdb742 fs/dcache: use swait_queue instead
> of
> waitqueue
…
> The following change is the obvious reason:
>
> --- a/kernel/sched/swait.c
> +++ b/kernel/sched/swait.c
> @@ -69,6 +
Starting with the change
8a64547a07980f9d25e962a78c2e10ee82bdb742 fs/dcache: use swait_queue
instead of
waitqueue
we are getting the following warning when running with PREEMPT__LL when
inserting
a USB drive. This is on x86_64, 4.14.15-rt13. It works fine with
PREEMPT_RT.
# [ 155.604042
19 matches
Mail list logo
