[libvirt] [PATCH 1/2] cgroup: Add accessors for cpuset.memory_migrate
Martin Kletzander
mkletzan at redhat.com
Fri Mar 20 08:55:55 UTC 2015
On Thu, Mar 19, 2015 at 05:25:28PM -0600, Eric Blake wrote:
>On 03/19/2015 05:11 PM, John Ferlan wrote:
>
>>> +int
>>> +virCgroupSetCpusetMemoryMigrate(virCgroupPtr group, bool migrate)
>>> +{
>>> + return virCgroupSetValueStr(group,
>>> + VIR_CGROUP_CONTROLLER_CPUSET,
>>> + "cpuset.memory_migrate",
>>> + migrate ? "1" : "0");
>>> +}
>>
>> are my eyes deceiving me?... boolean here (1 or 0)
>
>No, the kernel really works this way - it takes the human-readable
>string "1" or "0" rather than the C byte '\1' or '\0', so this is the
>lowest level in the stack where we convert our convenient bool for
>everyone above us into the string literal the kernel cgroup interface
>expects.
>
Yes, exactly. I could've also used SetValueU64(), but that formats
that value which is unnecessary overhead.
>>> +int
>>> +virCgroupGetCpusetMemoryMigrate(virCgroupPtr group, bool *migrate)
>>> +{
>>> + unsigned long long value = 0;
>>> + int ret = virCgroupGetValueU64(group,
>>
>> But we're getting a U64 here? for what's documented as "contains a flag
>> (0 or 1)
>>
>>> + VIR_CGROUP_CONTROLLER_CPUSET,
>>> + "cpuset.memory_migrate",
>>> + &value);
>>> + *migrate = !!value;
>
>And here, this is one easy way to turn the kernel's string back into a
>bool (it might also be possible to read as a string, and then do
>*str=='1', rather than going through an intermediate integer conversion,
>but I'm not sure it is worth the micro-optimization).
>
With one exception. If kernel changes the possible values to
something else (let's say they'll add "2" for some special new
meaning like "move aggressively"), this code will still work.
>--
>Eric Blake eblake redhat com +1-919-301-3266
>Libvirt virtualization library http://libvirt.org
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150320/34749f89/attachment-0001.sig>
More information about the libvir-list
mailing list