On Thu, Nov 11, 2010 at 01:34:26AM +0900, Masao Uebayashi wrote: > On Wed, Nov 10, 2010 at 10:27:50AM -0600, David Young wrote: > > On Tue, Nov 09, 2010 at 12:36:16PM +0900, Masao Uebayashi wrote: > > > The root cause of such a problem is, we don't do I/O scheduling at all. > > > > > > I think that pool(9) (and pool_cache(9)) is a great tool to manage > > > limited resources. The way to go would be to extend it to manage > > > bandwidth in I/O subsystems. (We already use pool_cache(9) for > > > KVA.) > > > > > > Resources are shared, and have dependencies. I/O resources would > > > look like some hierachical structure chained with pool backend > > > callbacks. Probably combined with device tree too. > > > > FWIW, I'm working on managing PCI I/O resources in this way, but I'm > > probably going to use vmem(9), not pool(9). > > That is PCI I/O *space*, right? I agree vmem(9) is suitable for that. > > What I meant is I/O descriptors like mbuf or struct buf. Something like > altq generalized for I/O queues.
Sorry, I'd lost track of what was under discussion. ALTQ for I/O queues? How would that work? Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
