On 07/03, Hugh Dickins wrote:
>
> Thank you, Oleg. But, with respect, I'd caution against making it cleverer
> at the last minute: what you posted already is understandable, works, has
> Jen's Reviewed-by and my Acked-by: it just lacks a description and signoff.
OK, agreed. I am sending that
On 7/3/19 11:35 AM, Oleg Nesterov wrote:
> On 07/02, Andrew Morton wrote:
>
>> On Mon, 1 Jul 2019 08:22:32 -0600 Jens Axboe wrote:
>>
>>> Andrew, can you queue Oleg's patch for 5.2? You can also add my:
>>>
>>> Reviewed-by: Jens Axboe
>>
>> Sure. Although things are a bit of a mess. Oleg, can
On Wed, 3 Jul 2019, Oleg Nesterov wrote:
> On 07/02, Andrew Morton wrote:
> > On Mon, 1 Jul 2019 08:22:32 -0600 Jens Axboe wrote:
> >
> > > Andrew, can you queue Oleg's patch for 5.2? You can also add my:
> > >
> > > Reviewed-by: Jens Axboe
> >
> > Sure. Although things are a bit of a mess.
On 07/02, Andrew Morton wrote:
> On Mon, 1 Jul 2019 08:22:32 -0600 Jens Axboe wrote:
>
> > Andrew, can you queue Oleg's patch for 5.2? You can also add my:
> >
> > Reviewed-by: Jens Axboe
>
> Sure. Although things are a bit of a mess. Oleg, can we please have a
> clean resend with signoffs
On Mon, 1 Jul 2019 08:22:32 -0600 Jens Axboe wrote:
> Andrew, can you queue Oleg's patch for 5.2? You can also add my:
>
> Reviewed-by: Jens Axboe
Sure. Although things are a bit of a mess. Oleg, can we please have a
clean resend with signoffs and acks, etc?
On 6/30/19 5:06 PM, Hugh Dickins wrote:
> On Wed, 5 Jun 2019, Jens Axboe wrote:
>>
>> How about the following plan - if folks are happy with this sched patch,
>> we can queue it up for 5.3. Once that is in, I'll kill the block change
>> that special cases the polled task wakeup. For 5.2, we go
On Wed, 5 Jun 2019, Jens Axboe wrote:
>
> How about the following plan - if folks are happy with this sched patch,
> we can queue it up for 5.3. Once that is in, I'll kill the block change
> that special cases the polled task wakeup. For 5.2, we go with Oleg's
> patch for the swap case.
I just
+
Hi Peter, Jen,
As we are not taking pi_lock here , is there possibility of same task dead
call comes as this point of time for current thread, bcoz of which we have
seen earlier issue after this commit 0619317ff8ba
[T114538] do_task_dead+0xf0/0xf8
[T114538] do_exit+0xd5c/0x10fc
On 06/10, Gaurav Kohli wrote:
>
> >@@ -1991,6 +1991,28 @@ try_to_wake_up(struct task_struct *p, un
> > unsigned long flags;
> > int cpu, success = 0;
> >+if (p == current) {
> >+/*
> >+ * We're waking current, this means 'p->on_rq' and 'task_cpu(p)
> >+
On 6/7/2019 7:53 PM, Peter Zijlstra wrote:
On Fri, Jun 07, 2019 at 03:35:41PM +0200, Peter Zijlstra wrote:
On Wed, Jun 05, 2019 at 09:04:02AM -0600, Jens Axboe wrote:
How about the following plan - if folks are happy with this sched patch,
we can queue it up for 5.3. Once that is in, I'll
On 6/7/19 8:23 AM, Peter Zijlstra wrote:
> On Fri, Jun 07, 2019 at 03:35:41PM +0200, Peter Zijlstra wrote:
>> On Wed, Jun 05, 2019 at 09:04:02AM -0600, Jens Axboe wrote:
>>> How about the following plan - if folks are happy with this sched patch,
>>> we can queue it up for 5.3. Once that is in,
On Fri, Jun 07, 2019 at 03:35:41PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 05, 2019 at 09:04:02AM -0600, Jens Axboe wrote:
> > How about the following plan - if folks are happy with this sched patch,
> > we can queue it up for 5.3. Once that is in, I'll kill the block change
> > that special
On Wed, Jun 05, 2019 at 09:04:02AM -0600, Jens Axboe wrote:
> How about the following plan - if folks are happy with this sched patch,
> we can queue it up for 5.3. Once that is in, I'll kill the block change
> that special cases the polled task wakeup. For 5.2, we go with Oleg's
> patch for the
On 6/3/19 6:37 AM, Peter Zijlstra wrote:
> On Fri, May 31, 2019 at 03:12:13PM -0600, Jens Axboe wrote:
>> On 5/30/19 2:03 AM, Peter Zijlstra wrote:
>
>>> What is the purpose of that patch ?! The Changelog doesn't mention any
>>> benefit or performance gain. So why not revert that?
>>
>> Yeah that
On 6/3/19 6:37 AM, Peter Zijlstra wrote:
> On Fri, May 31, 2019 at 03:12:13PM -0600, Jens Axboe wrote:
>> On 5/30/19 2:03 AM, Peter Zijlstra wrote:
>
>>> What is the purpose of that patch ?! The Changelog doesn't mention any
>>> benefit or performance gain. So why not revert that?
>>
>> Yeah that
On Mon, Jun 03, 2019 at 06:09:53PM +0200, Oleg Nesterov wrote:
> On 06/03, Peter Zijlstra wrote:
> >
> > It now also has concurrency on wakeup; but afaict that's harmless, we'll
> > get racing stores of p->state = TASK_RUNNING, much the same as if there
> > was a remote wakeup vs a wait-loop
On 06/03, Peter Zijlstra wrote:
>
> It now also has concurrency on wakeup; but afaict that's harmless, we'll
> get racing stores of p->state = TASK_RUNNING, much the same as if there
> was a remote wakeup vs a wait-loop terminating early.
>
> I suppose the tracepoint consumers might have to deal
On Mon, Jun 03, 2019 at 02:37:05PM +0200, Peter Zijlstra wrote:
> Anyway, Oleg, do you see anything blatantly buggered with this patch?
>
> (the stats were already dodgy for rq-stats, this patch makes them dodgy
> for task-stats too)
It now also has concurrency on wakeup; but afaict that's
On Fri, May 31, 2019 at 03:12:13PM -0600, Jens Axboe wrote:
> On 5/30/19 2:03 AM, Peter Zijlstra wrote:
> > What is the purpose of that patch ?! The Changelog doesn't mention any
> > benefit or performance gain. So why not revert that?
>
> Yeah that is actually pretty weak. There are substantial
On 5/30/19 2:03 AM, Peter Zijlstra wrote:
> On Wed, May 29, 2019 at 04:25:26PM -0400, Qian Cai wrote:
>
>> Fixes: 0619317ff8ba ("block: add polled wakeup task helper")
>
> What is the purpose of that patch ?! The Changelog doesn't mention any
> benefit or performance gain. So why not revert
On 5/30/19 5:15 AM, Oleg Nesterov wrote:
> On 05/29, Qian Cai wrote:
>>
>> The commit 0619317ff8ba ("block: add polled wakeup task helper")
>> replaced wake_up_process() with blk_wake_io_task() in
>> end_swap_bio_read() which triggers a crash when running heavy swapping
>> workloads.
>>
>>
On 05/29, Qian Cai wrote:
>
> The commit 0619317ff8ba ("block: add polled wakeup task helper")
> replaced wake_up_process() with blk_wake_io_task() in
> end_swap_bio_read() which triggers a crash when running heavy swapping
> workloads.
>
> [T114538] kernel BUG at kernel/sched/core.c:3462!
>
On Wed, May 29, 2019 at 04:25:26PM -0400, Qian Cai wrote:
> Fixes: 0619317ff8ba ("block: add polled wakeup task helper")
What is the purpose of that patch ?! The Changelog doesn't mention any
benefit or performance gain. So why not revert that?
> Signed-off-by: Qian Cai
> ---
>
On 5/29/19 2:25 PM, Qian Cai wrote:
> The commit 0619317ff8ba ("block: add polled wakeup task helper")
> replaced wake_up_process() with blk_wake_io_task() in
> end_swap_bio_read() which triggers a crash when running heavy swapping
> workloads.
>
> [T114538] kernel BUG at
The commit 0619317ff8ba ("block: add polled wakeup task helper")
replaced wake_up_process() with blk_wake_io_task() in
end_swap_bio_read() which triggers a crash when running heavy swapping
workloads.
[T114538] kernel BUG at kernel/sched/core.c:3462!
[T114538] Process oom01 (pid: 114538, stack
25 matches
Mail list logo
