Re: [patch] kwaitd, 2.5.31-A1

[Andrew Morton]

Ingo Molnar wrote:
> 
> ...
> the reaping of the thread is thus not done by the parent (or init), but by
> per-CPU [kwaitd] kernel threads. The exiting thread queues itself always
> to the CPU-local kwaitd queue, to maintain locality of reference and cheap
> switching to kwaitd.

I'd be inclined to agree with hch on that.  We have an awful lot of
kernel threads nowadays, and keventd would fill the bill.

Andrea's kernels have keventd running SCHED_RR, and that's appropriate
to this application also.   Not sure about AIO though.

> [ this new reaping method could also be used when reparenting to init -
> but i'm unsure whether this would really work as expected - do some init
> variants rely perhaps on getting all orphan tasks in the system? ]

That should be OK.  init never knew about the reparented ones anyway.

> ...
> +
> +static kwait_t kwait_threads[NR_CPUS] __cacheline_aligned;
> +

We need to start using Rusty's percpu stuff sometime.

> +void reap_thread(task_t *p)
> +{
> +       kwait_t *kwait = kwait_threads + smp_processor_id();
> +

get_cpu() here?

> +
> +       if (p->parent == kwait->task) {
> +               printk("hm, %s(%d) reaped already.\n", p->comm, p->pid);
> +               return;
> +       }
> +       REMOVE_LINKS(p);

This is called under read_lock(&tasklist_lock), but modifies the
task list.

> ...
> +
> +                       schedule();
> +                       current->state = TASK_RUNNING;

schedule() always returns in state TASK_RUNNING?  (Or at least, it
used to.  Tell me if that changed, quick ;))

And a question: is it not possible to make the exitting task just go
and reap itself?  If it's a matter of freeing the stack pages we could
just add the page to a per-cpu deferred freeing list and reap it in
page reclaim.