| 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
| ||
|
Message-ID: <20080219094348.GE6485@one.firstfloor.org> Date: Tue, 19 Feb 2008 10:43:48 +0100 From: Andi Kleen <andi@...stfloor.org> To: David Chinner <dgc@....com>, Michael Tokarev <mjt@....msk.ru>, Ric Wheeler <ric@....com>, device-mapper development <dm-devel@...hat.com>, Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org Subject: Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices > My complaint about having to support them within dm when more than one > device is involved is because any efficiencies disappear: you can't send > further I/O to any one device until all the other devices have completed > their barrier (or else later I/O to that device could overtake the > barrier on another device). And then I argue that it would be better I was wondering: would it help DM to have the concept of a "barrier window" As in "this barrier is only affective for this group of requests" With such a concept DM would need to stall only inside the groups and possible even issue such barrier groups in parallel, couldn't it? I'm sure you guys all have thought far more about barriers than I ever did; if that idea came up before why was it dismissed? -Andi -- 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