linux-kernel - Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160307154936.GB7065@htj.duckdns.org>
Date:	Mon, 7 Mar 2016 10:49:36 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:	Jan Kara <jack@...e.cz>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	akpm@...ux-foundation.org, jack@...e.com, pmladek@...e.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

Hello,

On Tue, Mar 08, 2016 at 12:10:47AM +0900, Sergey Senozhatsky wrote:
> A new version. Switched to [printk] kthread.

There are some benefits to using a percpu workqueue with CPU_INTENSIVE
set or an unbound workqueue.  It'd need WQ_RESCUER so it'd still
create a dedicated thread which is used under heavy memory pressure
but workqueue will usaully give you local (cpu or node) worker.  One
reason to use kthread directly tho is minimizing the amount of
dependency which is pretty important for printk.  If we decide to use
kthread instead of workqueue, let's please do it for the right reason.

Thanks.

-- 
tejun