Re: [PATCHSET] cpuhog: implement and use cpuhog

[Peter Zijlstra <peterz@infradead.org>]

On Fri, 2010-03-12 at 12:13 +0900, Tejun Heo wrote:
> Hello, Peter.
> 
> On 03/11/2010 04:25 AM, Peter Zijlstra wrote:
> > cpuhog as a name doesn't work for me, stop-machine had a name that
> > described its severity and impact, cpuhog makes me think of while(1);.
> >
> > Can't we keep the stop_machine name and make that a workqueue interface
> > like you propose?
> >
> > That way we'd end up with something like:
> > 
> > kernel/stop_machine.c
> >   int stop_cpu(int cpu, stop_fn_t fn, void *arg)
> >   int stop_machine(struct cpumask *mask, stop_fn_t fn, void *arg)
> 
> The distinction would be diabling of IRQ on each CPU.
> hog_[one_]cpu[s]() schedule highest priority task to, well, hog the
> cpu but doesn't affect contextless part of the cpu (irq, bh, whatnot).
> In that sense, it is the lowest bottom of upper half but not quite
> stopping the cpu and I think the distinction is rather important to
> make.  With the proposed preemption disabling around the callback, it
> pretty much behaves like a complete hog too.

Its a pretty minor difference, shouldn't we simply audit all existing
kstopmachine users and fix that up, having two similar but not quite
identical interfaces in the kernel sounds like trouble.

> > alternatively, something like schedule_primary_work*() might work I
> > guess.
> 
> I wanted to avoid verbs associatffed with the traditional workqueue -
> schedule and queue, while emphasizing that this is something that you
> don't want to abuse - so the verb hog.  monopolize_cpu() was the
> second choice but hog is shorter, sweeter and can also be used as a
> noun as-is, so I chose hog.
> 
> So, those were my rationales.  What do you think?

Still don't like the name fwiw.