svn commit: r191405 - in head/sys: amd64/amd64 i386/i386

[Ivan Voras]

2009/4/23 Robert Watson <rwatson at freebsd.org>:
>
> On Thu, 23 Apr 2009, Ivan Voras wrote:
>
>> 2009/4/23 Robert Watson <rwatson at freebsd.org>:
>>
>>> Do you have any ideas about ways to usefully represent and manage
>>> concepts like "pick a close CPU" or "the set of CPUs that are close"?  For
>>> example, if I have available a flow identifier, hashing to one of a set of
>>> available CPUs is easy, but what would you suggest as an efficient
>>> representation to hash from a set of close available CPUs rather than the
>>> entire pool?
>>
>> Excuse me if I'm missing the point but isn't this already done by ULE and
>> for almost the same reasons? Shouldn't the scheduler (or its topology
>> infrastructure if it's separated from the scheduler) be the best place to do
>> it?
>
> Yes, the scheduler will presumably provide the abstractions we're interested
> in in order to implement this sort of policy.  However, the scheduler's
> notion of "strictly ordered events" is represented by a thread, and threads
> scale to several thousand per machine.  The network stack's notion of
> "strictly ordered events" is represented by a flow, and we need to be able
> to handle millions of those at once.  The mapping between flows and threads
> is something the network stack is best suited to do, since it will be
> passing around and ordering the work, but with the help of appropriate
> abstractions from the scheduler so that it knows how many and which threads
> exist to do the work, and so that it can use scheduler-provided metrics,
> such as CPU topology, to make reasonable choices about placement of work
> when there's flexibility in the ordering.

Thanks, it's much clearer now!