[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v3 00/14] Series short description
- To: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
- From: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
- Date: Tue, 19 Nov 2013 16:00:37 +0000
- Cc: Marcus Granado <Marcus.Granado@xxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Li Yechen <lccycc123@xxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxx>, Justin Weaver <jtweaver@xxxxxxxxxx>, Matt Wilson <msw@xxxxxxxxxx>, Elena Ufimtseva <ufimtseva@xxxxxxxxx>
- Delivery-date: Tue, 19 Nov 2013 16:01:03 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 11/18/2013 06:16 PM, Dario Faggioli wrote:
Implement vcpu soft affinity for credit1
Hello everyone,
Take 3 for his series.
Very briefly, what it does is allowing each vcpu to have:
- an hard affinity, which they already do, and we usually call pinning. This
is the list of pcpus where a vcpu is allowed to run;
- a soft affinity, which this series introduces. This is the list of pcpus
where a vcpu *prefers* to run.
Once that is done, per-vcpu NUMA-aware scheduling is easily implemented on top
of that, just by instructing libxl to issue the proper call to setup the soft
affinity of the domain's vcpus to be equal to its node-affinity.
Wrt v2 review[*] I have addressed all the comments (see individual changelogs).
In particular, I have completely redesigned the libxl interface. It now allows
both the following usage patterns:
1. changing either soft affinity only or hard affinity only or both of them to
the same value, and getting DEBUG or WARN output if that results in an
inconsistent state;
2. changing both hard and soft affinity, each one to its own value, and
getting DEBUG or WARN output only if the *final* state is inconsistent.
The series is also available here:
git://xenbits.xen.org/people/dariof/xen.git numa/per-vcpu-affinity-v3
Thanks and Regards,
Dario
Release-wise, I think this is probably not a blocker, but it is a very
cool feature. From a scheduler standpoint, it should be fairly low risk
-- it is primarily simplifying a mechanism that was introduced in 4.3.
Bugs in the library code should be fairly easy to catch, and fairly low
impact if they are found.
The primary thing to be concerned about is the interface; whether we
have had enough time to consider the new interfaces before committing to
support them. But they're fairly straightforward.
Since we're only a day past the freezing point, and (I think) almost
ready to be checked in, I'm inclined to give this a freeze exception.
Any other thoughts?
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
