Hello,
On Tue, Apr 10, 2018 at 10:13:33PM +0200, Vlastimil Babka wrote:
> > For percpu work items, they'll keep executing on the same cpu it
> > started on unless the cpu goes down while executing.
>
> Right, but before this patch, with just schedule_delayed_work() i.e.
> non-percpu? If such work
On 04/10/2018 09:53 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Apr 10, 2018 at 09:40:19PM +0200, Vlastimil Babka wrote:
>> On 04/10/2018 04:12 PM, Christopher Lameter wrote:
>>> On Tue, 10 Apr 2018, Vlastimil Babka wrote:
>>>
cache_reap() is initially scheduled in start_cpu_timer() via
sc
Hello,
On Tue, Apr 10, 2018 at 09:40:19PM +0200, Vlastimil Babka wrote:
> On 04/10/2018 04:12 PM, Christopher Lameter wrote:
> > On Tue, 10 Apr 2018, Vlastimil Babka wrote:
> >
> >> cache_reap() is initially scheduled in start_cpu_timer() via
> >> schedule_delayed_work_on(). But then the next ite
On 04/10/2018 04:12 PM, Christopher Lameter wrote:
> On Tue, 10 Apr 2018, Vlastimil Babka wrote:
>
>> cache_reap() is initially scheduled in start_cpu_timer() via
>> schedule_delayed_work_on(). But then the next iterations are scheduled via
>> schedule_delayed_work(), thus using WORK_CPU_UNBOUND.
On Tue, Apr 10, 2018 at 09:12:08AM -0500, Christopher Lameter wrote:
> > @@ -4074,7 +4086,8 @@ static void cache_reap(struct work_struct *w)
> > next_reap_node();
> > out:
> > /* Set up the next iteration */
> > - schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC));
> > +
On Tue, 10 Apr 2018, Vlastimil Babka wrote:
> cache_reap() is initially scheduled in start_cpu_timer() via
> schedule_delayed_work_on(). But then the next iterations are scheduled via
> schedule_delayed_work(), thus using WORK_CPU_UNBOUND.
That is a bug.. cache_reap must run on the same cpu since
6 matches
Mail list logo
