Re: Increasing MAXPHYS

Scott Long wrote:

> I agree that more threads just creates many more race
> complications.  Even if it didn't, the storage driver is a
> serialization point; it doesn't matter if you have a dozen g_*
> threads if only one of them can be in the top half of the driver at
> a time.  No amount of fine-grained locking is going to help this.

Well that depends on the driver and device..
We have multiple linux threads coming in the top under some
setups so it wouldn't be a problem.

> 
> I'd like to go in the opposite direction.  The queue-dispatch-queue
> model of GEOM is elegant and easy to extend, but very wasteful for
> the simple case, where the simple case is one or two simple
> partition transforms (mbr, bsdlabel) and/or a simple stripe/mirror
> transform.  None of these need a dedicated dispatch context in
> order to operate.  What I'd like to explore is compiling the GEOM
> stack at creation time into a linear array of operations that
> happen without a g_down/g_up context switch.  As providers and
> consumers taste each other and build a stack, that stack gets
> compiled into a graph, and that graph gets executed directly from
> the calling context, both from the dev_strategy() side on the top
> and the bio_done() on the bottom.  GEOM classes that need a
> detached context can mark themselves as such, doing so will prevent
> a graph from being created, and the current dispatch model will be
> retained.

I've considered similar ideas. Or providing a non-queuing options for
some simple transformations.


> 
> I expect that this will reduce i/o latency by a great margin, thus
> directly addressing the performance problem that FusionIO makes an
> example of.  I'd like to also explore having the g_bio model not
> require a malloc at every stage in the stack/graph; even though
> going through UMA is fairly fast, it still represents overhead that
> can be eliminated.  It also represents an out-of-memory failure
> case that can be prevented.
> 
> I might try to work on this over the summer.  It's really a
> research project in my head at this point, but I'm hopeful that
> it'll show results.
> 
> Scott
> 
> _______________________________________________ 
> freebsd-current_at_freebsd.org mailing list 
> http://lists.freebsd.org/mailman/listinfo/freebsd-current To
> unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"