On Sat, Apr 27, 2013 at 12:10 PM, Lee Braiden <[email protected]> wrote: > On 27/04/13 12:06, David Bruant wrote: > > Le 26/04/2013 23:23, Brian Anderson a écrit : > > I do think 50,000 I/O-performing tasks in a 32-bit process is within our > reach. Last year I demonstrated 500,000 simultaneous Rust tasks (that did > nothing but wait) in a 32-bit process, but there have been severe > regressions since. On Linux I think we can get the initial allocation > overhead for a single task into the ~2k range for sure. > > Still, one stack per I/O operation has a bad smell to it. Being forced to > create a new task (even if "only" 2k) because the 49000 previous ones are > sitting idle doesn't sound right. Not contacting the remote resource (disk, > network) would be worse. To do efficient IO, there got to be a cheap way to > start an IO and wait for it. Creating a task, doesn't sound cheap enough to > work at scale. > > > But we're not talking about creating a new task for every io operation as > the io module's usual under-the-hood strategy, surely? > > It seems to me that, by default, what we'd want is a sync api which under > the hood, creates one task per drive accessed, or maybe max(drives_in_use, > number_of_cores). I think the OS will make them async with the drive > hardware anyway, though, so number_of_cores doesn't matter. > > We wouldn't want to request 1000 different files (or seeks) at the same > time, from one drive, though, right? I know there is command queuing on > drives and all, but still... > > > -- > Lee
You want to make all of the I/O requests you can at the same time and the OS I/O scheduler will schedule them in the way that minimizes the work required. That's why systemd takes 2 seconds to do a full boot instead of 15-20 seconds. Although the topic of the discussion is mostly networking where you absolutely don't want to queue them. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
