[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] 2.6.10-rc1-udm1: multipath work in progress

> Yes - there's a FIXME to extend that, but I'm waiting for
> examples of such arguments: no point adding the facility 
> until we're sure something will need to use it.
> So far I have no concrete examples of anything needing it.

You are right for the load-level selector. I don't know how real
the selector I had in mind is (my impression when talking with
NUMA people). As I understood they would need to decide for every
io which path to take, based on a relation between the memory
of the io and the adapter. So you would need to get called for
every io (we could do that by using 1 as repeat count) and a way
to set this correlation. This would require individual selector

> I'm trying exporting a new 'struct path' to ps & hwh with
> space for them to add their own state information.
>   struct dm_dev *dev; // Not allowed to change this 
>   void *pscontext;
>   void *hwhcontext;
> [patches on laptop which I can't connect today]

That would help to quickly find selector and hw handler data
from a passed in path pointer. Especially on status info calls
the path lookup should be quick. Sounds good.

> > I don't would it help to provide an example patch?
> Most useful thing at present would be discussion of examples of 
> realistic alternative classes of path selection algorithms so 
> we can check how they fit into the framework.
> The two considered so far are round-robin (already implemented)
> and load-balancing (which I believe the current interface will
> support adequately, possibly with the addition of the PS
> arguments).

For the load-balancing part yes. And the rest depends on how realistic
the numa-selector is.

> > count to 0 then.
> Or 1, meaning call the PS for every I/O. 
> (Strongly discouraged, unless it's just to gather statistics - 
> I'd expect a load balancer to want to vary this number each time.)
> 0 means don't call it again until the path has failed.

You're right. I meant 1. For load-balancing I'd start with 32 or so.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]