From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757038AbcJXEyV (ORCPT ); Mon, 24 Oct 2016 00:54:21 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:35910 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbcJXEyT (ORCPT ); Mon, 24 Oct 2016 00:54:19 -0400 From: Minchan Kim X-Google-Original-From: Minchan Kim Date: Mon, 24 Oct 2016 13:54:13 +0900 To: Sergey Senozhatsky Cc: Minchan Kim , Andrew Morton , Sergey Senozhatsky , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] zram: adjust the number of zram thread Message-ID: <20161024045413.GC4938@blaptop> References: <1474526565-6676-1-git-send-email-minchan@kernel.org> <1474526565-6676-3-git-send-email-minchan@kernel.org> <20161021062327.GC527@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161021062327.GC527@swordfish> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 21, 2016 at 03:23:27PM +0900, Sergey Senozhatsky 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.