Messages in this thread | | | Date | Mon, 24 Oct 2016 14:29:05 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH 3/3] zram: adjust the number of zram thread |
| |
On (10/24/16 13:54), Minchan Kim wrote: > > On (09/22/16 15:42), Minchan Kim wrote: > > [..] > > > +static int __zram_cpu_notifier(void *dummy, unsigned long action, > > > + unsigned long cpu) > > > { > > > struct zram_worker *worker; > > > > > > - while (!list_empty(&workers.worker_list)) { > > > + switch (action) { > > > + case CPU_UP_PREPARE: > > > + worker = kmalloc(sizeof(*worker), GFP_KERNEL); > > > + if (!worker) { > > > + pr_err("Can't allocate a worker\n"); > > > + return NOTIFY_BAD; > > > + } > > > + > > > + worker->task = kthread_run(zram_thread, NULL, "zramd-%lu", cpu); > > > + if (IS_ERR(worker->task)) { > > > + kfree(worker); > > > + pr_err("Can't allocate a zram thread\n"); > > > + return NOTIFY_BAD; > > > + } > > > > well, strictly speaking we are have no strict bound-to-cpu (per-cpu) > > requirement here, we just want to have num_online_cpus() worker threads. > > if we fail to create one more worker thread nothing really bad happens, > > so I think we better not block that cpu from coming online. > > iow, always 'return NOTIFY_OK'. > > If it doesn't make code complicated, I will do that in next spin.
thanks. I think it won't. we don't really care how many workers we have, because the workers are not per-cpu. we just want to be as parallel as possible, but don't guarantee anything at all: who knows how those workers will be scheduled; may be we even can end up with just one active worker all the time, if other rq-s have higher prio tasks to run. there are many things that can be against us here. that's a massive complication of zram.
preventing CPU from coming online is a bit over-reaction.
-ss
| |