On 05/24/2017 07:34 PM, Andrey Ryabinin wrote:
On 05/24/2017 07:29 PM, Dmitry Safonov wrote:
On 05/24/2017 06:21 PM, Andrey Ryabinin wrote:
We already have infrastructure for virtualized vdso, however we use
it only to change LINUX_VERSION_NAME in container. Simply store container's
start time - ve->start_timespec in vdso variable - VDSO64_ve_start_timespec,
and use it in __vdso_clock_gettime() to calculate container's monotonic time.
Make uts_arch_setup_additional_pages()/uts_prep_vdso_pages_locked() to always
setup new vdso, since previous policy to setup vdso only if uts_ns->name.release
wouldn't work for virtualized __vdso_clock_gettime()
https://jira.sw.ru/browse/PSBM-66451
Signed-off-by: Andrey Ryabinin <[email protected]>
Well, that's all looks good, but I've two questions:
1. Where VDSO64_ve_start_timespec is set? I do not see that part.
in uts_arch_setup_additional_pages() and uts_prep_vdso_pages_locked()
Uhm, yes, but that means that ve_ts_write() is broken for
running CT.
2. The part with unconditional creation of vdso pages array in
uts_arch_setup_additional_pages()/uts_prep_vdso_pages_locked()
will result in each exec() creating new vdso for all tasks in CT.
So, that will result in n*8kB additional memory, where n is
number of exec()'ed tasks in CTs.
I'm not sure how much can be n, so that may be OK.
But can we find a way to make it p*8kB, where p - is nr. of CTs?
Nope, vdso pages created only once, and attached to uts_ns. Once pages created
all follow up execs will reuse them. So it's one vdso per uts_ns.
Oh, good - I've just misread that code.
So, that should be fine.
As far as I can see, vdso pages array was also copied for UTS
virtualization where it was needed previously, so (2) question may be
not related to this patches set, but for the way how it is done
already. FWIW, what I mean here - it would be worth to have one copy
of vdso pages per-CT.
May be I'm trying to rearrange the deck chairs on the Titanic and
that increase is just insignificant.
---
--
Dmitry
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
