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
| ||
|
Date: Fri, 22 Oct 2010 10:09:21 +0200 From: Jens Axboe <axboe@...nel.dk> To: Wu Fengguang <fengguang.wu@...el.com> CC: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, Torsten Kaiser <just.for.lkml@...glemail.com>, Neil Brown <neilb@...e.de>, Rik van Riel <riel@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "Li, Shaohua" <shaohua.li@...el.com> Subject: Re: Deadlock possibly caused by too_many_isolated. On 2010-10-22 10:07, Wu Fengguang wrote: >>> We surely need 1 set aside for each level of that stack that will >>> potentially consume one. 1 should be enough for the generic pool, and >>> then clones will use a separate pool. So md and friends should really >>> have a pool per device, so that stacking will always work properly. >> >> Agreed for the deadlock problem. >> >>> There should be no throughput concerns, it should purely be a safe guard >>> measure to prevent us deadlocking when doing IO for reclaim. >> >> It's easy to verify whether the minimal size will have negative >> impacts on IO throughput. In Torsten's case, increase BIO_POOL_SIZE >> by one and check how it performs. > > Sorry it seems simply increasing BIO_POOL_SIZE is not enough to fix > possible deadlocks. We need adding new mempool(s). Because when there > BIO_POOL_SIZE=2 and there are two concurrent reclaimers each take 1 > reservation, they will deadlock each other when trying to take the > next bio at the raid1 level. Yes, plus it's not a practical solution since you don't know how deep the stack is. As I wrote in the initial email, each consumer needs it's own private mempool (and just 1 entry should suffice). -- Jens Axboe -- 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/
Powered by blists - more mailing lists