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, 2 Feb 2007 09:05:20 +0530 From: Suparna Bhattacharya <suparna@...ibm.com> To: Zach Brown <zach.brown@...cle.com> Cc: Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org, linux-aio@...ck.org, Benjamin LaHaise <bcrl@...ck.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH 4 of 4] Introduce aio system call submission and completion system calls On Thu, Feb 01, 2007 at 02:18:55PM -0800, Zach Brown wrote: > >Wooo ...hold on ... I think this is swinging out of perspective :) > > I'm sorry, but I don't. I think using the EIOCBRETRY method in > complicated code paths requires too much maintenance cost to justify > its benefits. We can agree to disagree on that judgement :). I don't disagree about limitations of the EIOCBRETRY approach, nor do I recommend it for all sorts of complicated code paths. It is only good as an approximation for specific blocking points involving idempotent behaviour, and I was trying to emphasise that that is *all* it was ever intended for. I certainly do not see it as a viable path to make all syscalls asynchronous, or to address all blocking points in filesystem IO. And I do like the general direction of your approach, only need to think deeper about the details like how to reduce stack per IO request so this can scale better. So we don't disagree as much as you think :) The point where we seem to disagree is that I think there is goodness in maintaining the conceptual clarity between what parts of the operation assume that it is executing in the original submitters context. For the IO paths this is what allows things like readahead and writeback to work and to cluster operations which may end up to/from multiple submitters. This means that if there is some context that is needed thereafter it could be associated with the IO request (as an argument or in some other manner), so that this division is still maintained. Regards Suparna > > - z > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to majordomo@...ck.org. For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: <a href=mailto:"aart@...ck.org">aart@...ck.org</a> -- Suparna Bhattacharya (suparna@...ibm.com) Linux Technology Center IBM Software Lab, India - 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