lkml.org 
[lkml]   [2016]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2016-10-24 07:29    [W:0.152 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site