linux-kernel - Re: [PATCH 1/2] workqueue: always pass cascading responsibility to the next flusher

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20140527142736.GD22767@htj.dyndns.org>
Date:	Tue, 27 May 2014 10:27:36 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] workqueue: always pass cascading responsibility to
 the next flusher

On Tue, May 27, 2014 at 10:24:43AM -0400, Tejun Heo wrote:
> So, I think hiding latencies which can easily in millisecs range is
> important.  It isn't a performance optimization.  It almost becomes a
> correctness issue when the problem is severely hit and the amount of

Another way to think about it is considering flushing an event
notification mechanism.  Doing the above can reliably induce tens of
millisecs of latency in event delivery on the right combination of
work items and flush patterns, which isn't acceptable.  We sure still
can fail to such state when the flush color space is exhausted but
this is a lot easier to trigger.

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/