On 08/19/2016 02:05 AM, Vijay Kilari wrote:
On Thu, Aug 18, 2016 at 8:26 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
On 18 August 2016 at 15:46, Richard Henderson <r...@twiddle.net> wrote:
On 08/18/2016 07:14 AM, Peter Maydell wrote:
While we're on the subject, can somebody explain to me why we
use ifuncs at all? I couldn't work out why it would be better than
just using a straightforward function pointer -- when I tried single
stepping through things the ifunc approach still seemed to indirect
through some table or other so it wasn't actually resolving to
a direct function call anyway.
No reason, I suppose.
It's particularly helpful for libraries, where we don't really want the
overhead of the initialization when it's not used.
Ah, I see.
But (1) we don't have many of these and (2) we really don't care *that* much
about startup time.
So a simple function pointer initialized by a constructor has the same
effect.
The cutils does not have any initialization function that can init
function/constructor pointer
for zero_check function.
static void __attribute__((constructor)) init_buffer_find_nonzero(void)
{
...
}
Also creating separate function with most of repeated code for prefetch does
not look good.
Why do you say that?
So suggest to put check for prefetch outside the for loop and
code for loop with and without prefetch
You're duplicating the inner loop either way, so that can't be your objection
to creating a separate function.
I profiled and found that a single check inside the loop is adding 100ms delay
for 8GB RAM migration.
That's about what I expected.
Also, If you want to make prefetch common for all arm64 platforms,
Then thunder cache line is 128 bytes so the prefetch is performed
at 128 byte index. If the platform has 64 byte cache line, then this
prefetch will fill only 64 byte line instead of 128 bytes required for the loop.
Yes, I had thought of that.
It would make sense to create two versions, that prefetch for and iterate over,
cacheline sizes of 64 and 128 (I don't know of any other common sizes).
Preferably, we should then use sysconf(_SC_LEVEL1_DCACHE_LINESIZE) within the
init function above to choose the appropriate version.
But I see that glibc doesn't currently implement that for aarch64, so we do
want to have a fallback. I know that the "official" cache line data isn't
(easily) available to userspace, but a close proxy is the size described by
dczid_el0. That seems much better than groveling through a file under /sys.
r~
