linux-kernel - Re: [PATCH] mm,vmscan: Use accurate values for zone

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: <20151023182343.GB14610@mtj.duckdns.org>
Date:	Sat, 24 Oct 2015 03:23:43 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	mhocko@...nel.org, cl@...ux.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	rientjes@...gle.com, oleg@...hat.com, kwalker@...hat.com,
	akpm@...ux-foundation.org, hannes@...xchg.org,
	vdavydov@...allels.com, skozina@...hat.com, mgorman@...e.de,
	riel@...hat.com
Subject: Re: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable()
 checks

Hello, Tetsuo.

On Fri, Oct 23, 2015 at 09:25:11PM +0900, Tetsuo Handa wrote:
> WQ_MEM_RECLAIM only guarantees that a "struct task_struct" is preallocated
> in order to avoid failing to allocate it on demand due to a GFP_KERNEL
> allocation? Is this correct?
> 
> WQ_CPU_INTENSIVE only guarantees that work items don't participate in
> concurrency management in order to avoid failing to wake up a "struct
> task_struct" which will process the work items? Is this correct?

CPU_INTENSIVE avoids the tail end of concurrency management.  The
previous HIGHPRI or the posted IMMEDIATE avoids the head end.

> Is Michal's question "does it make sense to use WQ_MEM_RECLAIM without
> WQ_CPU_INTENSIVE"? In other words, any "struct task_struct" which calls
> rescuer_thread() must imply WQ_CPU_INTENSIVE in order to avoid failing to
> wake up due to being participated in concurrency management?

If this is an actual problem, a better approach would be something
which detects the stall condition and kicks off the next work item but
if we do that I think I'd still trigger a warning there.  I don't
know.  Don't go busy waiting in kernel.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/