On Tue, Nov 20, 2018 at 08:33:19AM -0800, Tejun Heo wrote:
> On Mon, Nov 19, 2018 at 08:45:54AM -0800, Daniel Jordan wrote:
> > So instead of flush_work_at_nice, how about this?:
> >
> > void renice_work_sync(work_struct *work, long nice);
>
> Wouldn't renice_or_cancel make more sense?
I guess y
On Mon, Nov 19, 2018 at 08:45:54AM -0800, Daniel Jordan wrote:
> So instead of flush_work_at_nice, how about this?:
>
> void renice_work_sync(work_struct *work, long nice);
Wouldn't renice_or_cancel make more sense?
Thanks.
--
tejun
On Tue, Nov 13, 2018 at 08:34:00AM -0800, Tejun Heo wrote:
> Hello, Daniel.
Hi Tejun, sorry for the delay. Plumbers...
> On Mon, Nov 05, 2018 at 11:55:50AM -0500, Daniel Jordan wrote:
> > static bool start_flush_work(struct work_struct *work, struct wq_barrier
> > *barr,
> > -
Hello, Daniel.
On Mon, Nov 05, 2018 at 11:55:50AM -0500, Daniel Jordan wrote:
> static bool start_flush_work(struct work_struct *work, struct wq_barrier
> *barr,
> - bool from_cancel)
> + struct nice_work *nice_work, int flags)
> {
> struc
With ktask helper threads running at MAX_NICE, it's possible for one or
more of them to begin chunks of the task and then have their CPU time
constrained by higher priority threads. The main ktask thread, running
at normal priority, may finish all available chunks of the task and then
wait on the
5 matches
Mail list logo