linux-kernel - Re: [PATCH 0 of 4] Generic AIO by scheduling stacks

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <23588500-5AD3-48E1-A6F7-679E9DC9C4FC@oracle.com>
Date:	Tue, 30 Jan 2007 14:53:18 -0800
From:	Zach Brown <zach.brown@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, linux-aio@...ck.org,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: [PATCH 0 of 4] Generic AIO by scheduling stacks

> So we should limit these to basically have some maximum concurrency
> factor, but rather than consider it an error to go over it, we'd  
> just cap
> the concurrency by default, so that people can freely use asynchronous
> interfaces without having to always worry about what happens if their
> resources run out..

Yeah, call it the socket transmit queue model :).  Maybe tuned by a  
ulimit?

I don't have very strong opinions abou the specific mechanics of  
limiting concurrent submissions, as long as they're there.  Some  
folks in Oracle complain about having one more thing to have to tune,  
but the alternative seems worse.

> However, that also implies that we should probably add a "flags"  
> parameter
> to "async_submit()" and have a FIBRIL_IMMEDIATE flag (or a timeout) or
> something to tell the kernel to rather return EAGAIN than wait.  
> Sometimes
> you don't want to block just because you already have too much work.

EAGAIN or the initial number of submissions completed before the one  
that ran over the limit, perhaps.  Sure.  Nothing too controversial  
here :).   I have this kind of stuff queued up for worrying about  
once the internal mechanics are stronger.

- z

-
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/