Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int flags) defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov maxim.uvarov@linaro.com --- .../kernel/syscalls/cacheflush/cacheflush01.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */ +#if defined(__arm__) + TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr + getpagesize(), 0)); + if (TEST_RETURN == 0) { + tst_resm(TPASS, "passed with no errno"); + } else { + tst_resm(TFAIL, "failed with unexpected errno"); + } +#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(), ICACHE)); if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno"); @@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();
What's the overhead of a system call compared to the cost of the actual flush operation? What's the expected use case (specifically number of bytes flushed) of this call? (Maybe this is completely out of our control).
This is a flush (and invalidate) operation, not a true invalidate operation I assume, so it could be performed completely in user space, no supervisor privileges required. Is a user space implementation (using a DSO) contemplated?
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 03 October 2013 14:08 To: linaro-networking@linaro.org Cc: patches@linaro.org; linaro-kernel@lists.linaro.org; Maxim Uvarov Subject: [LNG] [PATCH] LTP cacheflush01 add arm variant
Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int flags) defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov maxim.uvarov@linaro.com
.../kernel/syscalls/cacheflush/cacheflush01.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */+#if defined(__arm__)
TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr + getpagesize(),0));
if (TEST_RETURN == 0) {tst_resm(TPASS, "passed with no errno");} else {tst_resm(TFAIL, "failed with unexpected errno");}+#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(), ICACHE)); if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno"); @@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();-- 1.7.9.5
-- You received this message because you are subscribed to the Google Groups "Linaro Networking" group. To unsubscribe from this group and stop receiving emails from it, send an email to linaro-networking+unsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.org.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On 10/04/2013 03:13 PM, Ola Liljedahl wrote:
What's the overhead of a system call compared to the cost of the actual flush operation?
Why are you asking about that? There should be some overhead but I don't think that somebody measured it.
What's the expected use case (specifically number of bytes flushed) of this call? (Maybe this is completely out of our control).
Well, it calls:
flush_cache_user_range(start, end);
coherent_user_range
* v7_coherent_user_range(start,end) * * Ensure that the I and D caches are coherent within specified * region. This is typically used when code has been written to * a memory region, and will be executed. * * - start - virtual start address of region * - end - virtual end address of region
-EFAULT - virt address not mapped, -EINVAL - wrong start/end arguments, 0 - on success.
Original (mips only I suppose) test does not do any invalid parameters check. So I just added only right case.
This is a flush (and invalidate) operation, not a true invalidate operation I assume, so it could be performed completely in user space, no supervisor privileges required. Is a user space implementation (using a DSO) contemplated?
Did not understand that. What is "user space implementation using DSO" ?
Thank you, Maxim.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 03 October 2013 14:08 To: linaro-networking@linaro.org Cc: patches@linaro.org; linaro-kernel@lists.linaro.org; Maxim Uvarov Subject: [LNG] [PATCH] LTP cacheflush01 add arm variant
Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int flags) defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov maxim.uvarov@linaro.com
.../kernel/syscalls/cacheflush/cacheflush01.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */+#if defined(__arm__)
TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr + getpagesize(),0));
if (TEST_RETURN == 0) {tst_resm(TPASS, "passed with no errno");} else {tst_resm(TFAIL, "failed with unexpected errno");}+#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(), ICACHE)); if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno"); @@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();-- 1.7.9.5
-- You received this message because you are subscribed to the Google Groups "Linaro Networking" group. To unsubscribe from this group and stop receiving emails from it, send an email to linaro-networking+unsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.org.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 04 October 2013 13:44 To: Ola Liljedahl Cc: linaro-networking@linaro.org; patches@linaro.org; linaro- kernel@lists.linaro.org Subject: Re: [LNG] [PATCH] LTP cacheflush01 add arm variant
On 10/04/2013 03:13 PM, Ola Liljedahl wrote:
What's the overhead of a system call compared to the cost of the actual
flush operation? Why are you asking about that? There should be some overhead but I don't think that somebody measured it.
[Ola] Because system calls are expensive and if we are only going to flush/invalidate a small amount of data but rather frequently (e.g. packet buffers in the days of incoherent I/O devices), doing this operation through a system call would degrade performance. This did look like a Linux system call.
What's the expected use case (specifically number of bytes flushed) of
this call? (Maybe this is completely out of our control). Well, it calls:
flush_cache_user_range(start, end);
coherent_user_range
- v7_coherent_user_range(start,end)
- Ensure that the I and D caches are coherent within specified
- region. This is typically used when code has been written to
- a memory region, and will be executed.
[Ola] Flush cache is a poor name for this call that merely assures synchronisation between I and D-caches (because instructions have been written by the application and should later be executed).
- start - virtual start address of region
- end - virtual end address of region
-EFAULT - virt address not mapped, -EINVAL - wrong start/end arguments, 0 - on success.
Original (mips only I suppose) test does not do any invalid parameters check. So I just added only right case.
This is a flush (and invalidate) operation, not a true invalidate
operation I assume, so it could be performed completely in user space, no supervisor privileges required. Is a user space implementation (using a DSO) contemplated? Did not understand that. What is "user space implementation using DSO" ?
[Ola] I meant vDSO. A kernel call actually implemented in user space using a shared object. This to avoid the overhead of trapping in and out of the kernel which could be substantial compared to the cost of flushing and invalidating a few cache lines in the I- and D-caches. That's why I ask about typical usage. Would this system call be called from e.g. JIT compilers?
A true invalidate operation (no writeback of dirty cache lines, any modified data would get lost) is more dangerous and are probably not allowed to be performed from user space. But the need for such an operation is negligible.
-- Ola
Thank you, Maxim.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 03 October 2013 14:08 To: linaro-networking@linaro.org Cc: patches@linaro.org; linaro-kernel@lists.linaro.org; Maxim Uvarov Subject: [LNG] [PATCH] LTP cacheflush01 add arm variant
Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int flags) defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov maxim.uvarov@linaro.com
.../kernel/syscalls/cacheflush/cacheflush01.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */+#if defined(__arm__)
TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr + getpagesize(),0));
if (TEST_RETURN == 0) {tst_resm(TPASS, "passed with no errno");} else {tst_resm(TFAIL, "failed with unexpected errno");}+#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(), ICACHE)); if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno"); @@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();-- 1.7.9.5
-- You received this message because you are subscribed to the Google
Groups
"Linaro Networking" group. To unsubscribe from this group and stop receiving emails from it, send
an
email to linaro-networking+unsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.org.
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On 10/04/2013 06:04 PM, Ola Liljedahl wrote:
From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 04 October 2013 13:44 To: Ola Liljedahl Cc: linaro-networking@linaro.org; patches@linaro.org; linaro- kernel@lists.linaro.org Subject: Re: [LNG] [PATCH] LTP cacheflush01 add arm variant
On 10/04/2013 03:13 PM, Ola Liljedahl wrote:
What's the overhead of a system call compared to the cost of the actual
flush operation? Why are you asking about that? There should be some overhead but I don't think that somebody measured it.
[Ola] Because system calls are expensive and if we are only going to flush/invalidate a small amount of data but rather frequently (e.g. packet buffers in the days of incoherent I/O devices), doing this operation through a system call would degrade performance. This did look like a Linux system call.
What's the expected use case (specifically number of bytes flushed) of
this call? (Maybe this is completely out of our control). Well, it calls:
flush_cache_user_range(start, end);
coherent_user_range
- v7_coherent_user_range(start,end)
- Ensure that the I and D caches are coherent within specified
- region. This is typically used when code has been written to
- a memory region, and will be executed.
[Ola] Flush cache is a poor name for this call that merely assures synchronisation between I and D-caches (because instructions have been written by the application and should later be executed).
- start - virtual start address of region
- end - virtual end address of region
-EFAULT - virt address not mapped, -EINVAL - wrong start/end arguments, 0 - on success.
Original (mips only I suppose) test does not do any invalid parameters check. So I just added only right case.
This is a flush (and invalidate) operation, not a true invalidate
operation I assume, so it could be performed completely in user space, no supervisor privileges required. Is a user space implementation (using a DSO) contemplated? Did not understand that. What is "user space implementation using DSO" ?
[Ola] I meant vDSO. A kernel call actually implemented in user space using a shared object. This to avoid the overhead of trapping in and out of the kernel which could be substantial compared to the cost of flushing and invalidating a few cache lines in the I- and D-caches. That's why I ask about typical usage. Would this system call be called from e.g. JIT compilers?
A true invalidate operation (no writeback of dirty cache lines, any modified data would get lost) is more dangerous and are probably not allowed to be performed from user space. But the need for such an operation is negligible.
-- Ola
I don't really know where and how this syscall is used. I think it might be gdb or some applications with executable code to malloced area. Because of original problem was to fix 'there is no such syscall _NR_cacheflush' in testcases/kernel/syscalls/cachflush test. I.e. test is under syscall directory it has to be syscall.
And the other question is how it's better to use cacheflush with smaller overhead.
Also I do not see any user space include file for cacheflush(). arm-linux-gnueabihf- does not know how to compile it. So I still don't understand how to use cache flush with vDSO. Is it already implemented or it's just idea to do?
Maxim.
Thank you, Maxim.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 03 October 2013 14:08 To: linaro-networking@linaro.org Cc: patches@linaro.org; linaro-kernel@lists.linaro.org; Maxim Uvarov Subject: [LNG] [PATCH] LTP cacheflush01 add arm variant
Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int flags) defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov maxim.uvarov@linaro.com
.../kernel/syscalls/cacheflush/cacheflush01.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */+#if defined(__arm__)
TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr + getpagesize(),0));
if (TEST_RETURN == 0) {tst_resm(TPASS, "passed with no errno");} else {tst_resm(TFAIL, "failed with unexpected errno");}+#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(), ICACHE)); if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno"); @@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();-- 1.7.9.5
-- You received this message because you are subscribed to the Google
Groups
"Linaro Networking" group. To unsubscribe from this group and stop receiving emails from it, send
an
email to linaro-networking+unsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.org.
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On Fri, Oct 04, 2013 at 06:43:12PM +0400, Maxim Uvarov wrote:
On 10/04/2013 06:04 PM, Ola Liljedahl wrote:
From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 04 October 2013 13:44 To: Ola Liljedahl Cc: linaro-networking@linaro.org; patches@linaro.org; linaro- kernel@lists.linaro.org Subject: Re: [LNG] [PATCH] LTP cacheflush01 add arm variant
On 10/04/2013 03:13 PM, Ola Liljedahl wrote:
What's the overhead of a system call compared to the cost of the actual
flush operation? Why are you asking about that? There should be some overhead but I don't think that somebody measured it.
[Ola] Because system calls are expensive and if we are only going to flush/invalidate a small amount of data but rather frequently (e.g. packet buffers in the days of incoherent I/O devices), doing this operation through a system call would degrade performance. This did look like a Linux system call.
What's the expected use case (specifically number of bytes flushed) of
this call? (Maybe this is completely out of our control). Well, it calls:
flush_cache_user_range(start, end);
coherent_user_range
- v7_coherent_user_range(start,end)
- Ensure that the I and D caches are coherent within specified
- region. This is typically used when code has been written to
- a memory region, and will be executed.
[Ola] Flush cache is a poor name for this call that merely assures synchronisation between I and D-caches (because instructions have been written by the application and should later be executed).
- start - virtual start address of region
- end - virtual end address of region
-EFAULT - virt address not mapped, -EINVAL - wrong start/end arguments, 0 - on success.
Original (mips only I suppose) test does not do any invalid parameters check. So I just added only right case.
This is a flush (and invalidate) operation, not a true invalidate
operation I assume, so it could be performed completely in user space, no supervisor privileges required. Is a user space implementation (using a DSO) contemplated? Did not understand that. What is "user space implementation using DSO" ?
[Ola] I meant vDSO. A kernel call actually implemented in user space using a shared object. This to avoid the overhead of trapping in and out of the kernel which could be substantial compared to the cost of flushing and invalidating a few cache lines in the I- and D-caches. That's why I ask about typical usage. Would this system call be called from e.g. JIT compilers?
A true invalidate operation (no writeback of dirty cache lines, any modified data would get lost) is more dangerous and are probably not allowed to be performed from user space. But the need for such an operation is negligible.
-- Ola
I don't really know where and how this syscall is used. I think it might be gdb or some applications with executable code to malloced area. Because of original problem was to fix 'there is no such syscall _NR_cacheflush' in testcases/kernel/syscalls/cachflush test. I.e. test is under syscall directory it has to be syscall.
And the other question is how it's better to use cacheflush with smaller overhead.
Also I do not see any user space include file for cacheflush(). arm-linux-gnueabihf- does not know how to compile it. So I still don't understand how to use cache flush with vDSO. Is it already implemented or it's just idea to do?
Sorry for stepping into your discussion. Just a bit info about cacheslush and friends...
AFAIK discussed syscall is hidden for arm. It means it is not supposed to be called explicitly. Despite it is syscall it is called indirectly via gcc's built-in function: void __builtin___clear_cache (char *begin, char *end)
Short info from [1]:
This function is usead to flush the processor's instruction cache for the region of memory between begin inclusive and end exclusive. Some targets require that the instruction cache be flushed, after modifying memory containing code, in order to obtain deterministic behavior. If the target does not require instruction cache flushes, __builtin___clear_cache has no effect. Otherwise either instructions are emitted in-line to clear the instruction cache or a call to the __clear_cache function in libgcc is made.
Simple testcase
int main(void) { __builtin___clear_cache(0, 0); return 0; }
will be generated by gcc into
00000000 <main>: 0: b580 push {r7, lr} 2: af00 add r7, sp, #0 4: 2000 movs r0, #0 6: 2100 movs r1, #0 8: f7ff fffe bl 0 <__clear_cache> c: 2300 movs r3, #0 e: 4618 mov r0, r3 10: bd80 pop {r7, pc} 12: bf00 nop
You can see that "call" is just branch to kernel space address, something like vDSO (called kernel helpers in ARM Linux terminology [2]). So, it is optimized for user space.
In my opinion, LTP test in question is not applicable for ARM - it tests nothing. It'd be better to test that clear_cache do its job.
[1] http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html [2] linux/Documentation/arm/kernel_user_helpers.txt
Thanks Vladimir
Maxim.
Thank you, Maxim.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 03 October 2013 14:08 To: linaro-networking@linaro.org Cc: patches@linaro.org; linaro-kernel@lists.linaro.org; Maxim Uvarov Subject: [LNG] [PATCH] LTP cacheflush01 add arm variant
Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int flags) defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov maxim.uvarov@linaro.com
.../kernel/syscalls/cacheflush/cacheflush01.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */+#if defined(__arm__)
TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr + getpagesize(),0));
if (TEST_RETURN == 0) {tst_resm(TPASS, "passed with no errno");} else {tst_resm(TFAIL, "failed with unexpected errno");}+#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(), ICACHE)); if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno"); @@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();-- 1.7.9.5
-- You received this message because you are subscribed to the Google
Groups
"Linaro Networking" group. To unsubscribe from this group and stop receiving emails from it, send
an
email to linaro-networking+unsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.org.
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
Ola, this is work to get the regular LTP test suite running with regular Linux kernels, are you concerned about ODP efficiencies?
I imagine there will be very few syscalls made by ODP and that we would address those we do need on a case by case.
But I might be reading too much between the lines. Mike
On 4 October 2013 11:26, Vladimir Murzin murzin.v@gmail.com wrote:
On Fri, Oct 04, 2013 at 06:43:12PM +0400, Maxim Uvarov wrote:
On 10/04/2013 06:04 PM, Ola Liljedahl wrote:
From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 04 October 2013 13:44 To: Ola Liljedahl Cc: linaro-networking@linaro.org; patches@linaro.org; linaro- kernel@lists.linaro.org Subject: Re: [LNG] [PATCH] LTP cacheflush01 add arm variant
On 10/04/2013 03:13 PM, Ola Liljedahl wrote:
What's the overhead of a system call compared to the cost of the
actual
flush operation? Why are you asking about that? There should be some overhead but I
don't
think that somebody measured it.
[Ola] Because system calls are expensive and if we are only going to
flush/invalidate
a small amount of data but rather frequently (e.g. packet buffers in
the days of
incoherent I/O devices), doing this operation through a system call
would degrade
performance. This did look like a Linux system call.
What's the expected use case (specifically number of bytes flushed)
of
this call? (Maybe this is completely out of our control). Well, it calls:
flush_cache_user_range(start, end);
coherent_user_range
- v7_coherent_user_range(start,end)
- Ensure that the I and D caches are coherent within specified
- region. This is typically used when code has been written to
- a memory region, and will be executed.
[Ola] Flush cache is a poor name for this call that merely assures
synchronisation
between I and D-caches (because instructions have been written by the
application
and should later be executed).
- start - virtual start address of region
- end - virtual end address of region
-EFAULT - virt address not mapped, -EINVAL - wrong start/end arguments, 0 - on success.
Original (mips only I suppose) test does not do any invalid parameters check. So I just added only right case.
This is a flush (and invalidate) operation, not a true invalidate
operation I assume, so it could be performed completely in user
space, no
supervisor privileges required. Is a user space implementation (using
a
DSO) contemplated? Did not understand that. What is "user space implementation using
DSO" ?
[Ola] I meant vDSO. A kernel call actually implemented in user space
using a
shared object. This to avoid the overhead of trapping in and out of
the kernel
which could be substantial compared to the cost of flushing and
invalidating
a few cache lines in the I- and D-caches. That's why I ask about
typical usage.
Would this system call be called from e.g. JIT compilers?
A true invalidate operation (no writeback of dirty cache lines, any
modified
data would get lost) is more dangerous and are probably not allowed to
be
performed from user space. But the need for such an operation is
negligible.
-- Ola
I don't really know where and how this syscall is used. I think it might be gdb or some applications with executable code to malloced area. Because of
original
problem was to fix 'there is no such syscall _NR_cacheflush' in testcases/kernel/syscalls/cachflush test. I.e. test is under syscall directory it has to be syscall.
And the other question is how it's better to use cacheflush with smaller overhead.
Also I do not see any user space include file for cacheflush(). arm-linux-gnueabihf- does not know how to compile it. So I still don't understand how to use cache flush with vDSO. Is it already implemented or it's just idea to do?
Sorry for stepping into your discussion. Just a bit info about cacheslush and friends...
AFAIK discussed syscall is hidden for arm. It means it is not supposed to be called explicitly. Despite it is syscall it is called indirectly via gcc's built-in function: void __builtin___clear_cache (char *begin, char *end)
Short info from [1]:
This function is usead to flush the processor's instruction cache for the region of memory between begin inclusive and end exclusive. Some targets require that the instruction cache be flushed, after modifying memory containing code, in order to obtain deterministic behavior. If the target does not require instruction cache flushes, __builtin___clear_cache has no effect. Otherwise either instructions are emitted in-line to clear the instruction cache or a call to the __clear_cache function in libgcc is made.
Simple testcase
int main(void) { __builtin___clear_cache(0, 0); return 0; }
will be generated by gcc into
00000000 <main>: 0: b580 push {r7, lr} 2: af00 add r7, sp, #0 4: 2000 movs r0, #0 6: 2100 movs r1, #0 8: f7ff fffe bl 0 <__clear_cache> c: 2300 movs r3, #0 e: 4618 mov r0, r3 10: bd80 pop {r7, pc} 12: bf00 nop
You can see that "call" is just branch to kernel space address, something like vDSO (called kernel helpers in ARM Linux terminology [2]). So, it is optimized for user space.
In my opinion, LTP test in question is not applicable for ARM - it tests nothing. It'd be better to test that clear_cache do its job.
[1] http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html [2] linux/Documentation/arm/kernel_user_helpers.txt
Thanks Vladimir
Maxim.
Thank you, Maxim.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 03 October 2013 14:08 To: linaro-networking@linaro.org Cc: patches@linaro.org; linaro-kernel@lists.linaro.org; Maxim
Uvarov
Subject: [LNG] [PATCH] LTP cacheflush01 add arm variant
Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int
flags)
defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov maxim.uvarov@linaro.com
.../kernel/syscalls/cacheflush/cacheflush01.c | 9
+++++++++
1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */+#if defined(__arm__)
TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr +getpagesize(),
0));
if (TEST_RETURN == 0) {tst_resm(TPASS, "passed with no errno");} else {tst_resm(TFAIL, "failed with unexpected errno");}+#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(),
ICACHE));
if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno");@@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();-- 1.7.9.5
-- You received this message because you are subscribed to the Google
Groups
"Linaro Networking" group. To unsubscribe from this group and stop receiving emails from it,
send
an
email to linaro-networking+unsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.org.
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose
the
contents to any other person, use it for any purpose, or store or
copy the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Registered in England & Wales, Company No: 2548782
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
Mike I was a bit concerned about the implementation if this "system call" was intended for use from e.g. device drivers (flushing/invalidating the D-cache which was common in the past). But the purpose is different and the implementation seems efficient, not using any system call. It's my old RTOS/device driver genes manifesting themselves.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
From: Mike Holmes [mailto:mike.holmes@linaro.org] Sent: 04 October 2013 18:27 To: Vladimir Murzin Cc: Maxim Uvarov; linaro-networking@linaro.org; Ola Liljedahl; linaro-kernel@lists.linaro.org; patches@linaro.org Subject: Re: [LNG] [PATCH] LTP cacheflush01 add arm variant
Ola, this is work to get the regular LTP test suite running with regular Linux kernels, are you concerned about ODP efficiencies? I imagine there will be very few syscalls made by ODP and that we would address those we do need on a case by case. But I might be reading too much between the lines. Mike
On 4 October 2013 11:26, Vladimir Murzin <murzin.v@gmail.commailto:murzin.v@gmail.com> wrote: On Fri, Oct 04, 2013 at 06:43:12PM +0400, Maxim Uvarov wrote:
On 10/04/2013 06:04 PM, Ola Liljedahl wrote:
From: Maxim Uvarov [mailto:maxim.uvarov@linaro.orgmailto:maxim.uvarov@linaro.org] Sent: 04 October 2013 13:44 To: Ola Liljedahl Cc: linaro-networking@linaro.orgmailto:linaro-networking@linaro.org; patches@linaro.orgmailto:patches@linaro.org; linaro- kernel@lists.linaro.orgmailto:kernel@lists.linaro.org Subject: Re: [LNG] [PATCH] LTP cacheflush01 add arm variant
On 10/04/2013 03:13 PM, Ola Liljedahl wrote:
What's the overhead of a system call compared to the cost of the actual
flush operation? Why are you asking about that? There should be some overhead but I don't think that somebody measured it.
[Ola] Because system calls are expensive and if we are only going to flush/invalidate a small amount of data but rather frequently (e.g. packet buffers in the days of incoherent I/O devices), doing this operation through a system call would degrade performance. This did look like a Linux system call.
What's the expected use case (specifically number of bytes flushed) of
this call? (Maybe this is completely out of our control). Well, it calls:
flush_cache_user_range(start, end);
coherent_user_range
- v7_coherent_user_range(start,end)
- Ensure that the I and D caches are coherent within specified
- region. This is typically used when code has been written to
- a memory region, and will be executed.
[Ola] Flush cache is a poor name for this call that merely assures synchronisation between I and D-caches (because instructions have been written by the application and should later be executed).
- start - virtual start address of region
- end - virtual end address of region
-EFAULT - virt address not mapped, -EINVAL - wrong start/end arguments, 0 - on success.
Original (mips only I suppose) test does not do any invalid parameters check. So I just added only right case.
This is a flush (and invalidate) operation, not a true invalidate
operation I assume, so it could be performed completely in user space, no supervisor privileges required. Is a user space implementation (using a DSO) contemplated? Did not understand that. What is "user space implementation using DSO" ?
[Ola] I meant vDSO. A kernel call actually implemented in user space using a shared object. This to avoid the overhead of trapping in and out of the kernel which could be substantial compared to the cost of flushing and invalidating a few cache lines in the I- and D-caches. That's why I ask about typical usage. Would this system call be called from e.g. JIT compilers?
A true invalidate operation (no writeback of dirty cache lines, any modified data would get lost) is more dangerous and are probably not allowed to be performed from user space. But the need for such an operation is negligible.
-- Ola
I don't really know where and how this syscall is used. I think it might be gdb or some applications with executable code to malloced area. Because of original problem was to fix 'there is no such syscall _NR_cacheflush' in testcases/kernel/syscalls/cachflush test. I.e. test is under syscall directory it has to be syscall.
And the other question is how it's better to use cacheflush with smaller overhead.
Also I do not see any user space include file for cacheflush(). arm-linux-gnueabihf- does not know how to compile it. So I still don't understand how to use cache flush with vDSO. Is it already implemented or it's just idea to do?
Sorry for stepping into your discussion. Just a bit info about cacheslush and friends...
AFAIK discussed syscall is hidden for arm. It means it is not supposed to be called explicitly. Despite it is syscall it is called indirectly via gcc's built-in function: void __builtin___clear_cache (char *begin, char *end)
Short info from [1]:
This function is usead to flush the processor's instruction cache for the region of memory between begin inclusive and end exclusive. Some targets require that the instruction cache be flushed, after modifying memory containing code, in order to obtain deterministic behavior. If the target does not require instruction cache flushes, __builtin___clear_cache has no effect. Otherwise either instructions are emitted in-line to clear the instruction cache or a call to the __clear_cache function in libgcc is made.
Simple testcase
int main(void) { __builtin___clear_cache(0, 0); return 0; }
will be generated by gcc into
00000000 <main>: 0: b580 push {r7, lr} 2: af00 add r7, sp, #0 4: 2000 movs r0, #0 6: 2100 movs r1, #0 8: f7ff fffe bl 0 <__clear_cache> c: 2300 movs r3, #0 e: 4618 mov r0, r3 10: bd80 pop {r7, pc} 12: bf00 nop
You can see that "call" is just branch to kernel space address, something like vDSO (called kernel helpers in ARM Linux terminology [2]). So, it is optimized for user space.
In my opinion, LTP test in question is not applicable for ARM - it tests nothing. It'd be better to test that clear_cache do its job.
[1] http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html [2] linux/Documentation/arm/kernel_user_helpers.txt
Thanks Vladimir
Maxim.
Thank you, Maxim.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373tel:%2B46%20706%20866%20373 Skype: ola.liljedahl
-----Original Message----- From: Maxim Uvarov [mailto:maxim.uvarov@linaro.orgmailto:maxim.uvarov@linaro.org] Sent: 03 October 2013 14:08 To: linaro-networking@linaro.orgmailto:linaro-networking@linaro.org Cc: patches@linaro.orgmailto:patches@linaro.org; linaro-kernel@lists.linaro.orgmailto:linaro-kernel@lists.linaro.org; Maxim Uvarov Subject: [LNG] [PATCH] LTP cacheflush01 add arm variant
Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int flags) defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.commailto:maxim.uvarov@linaro.com>
.../kernel/syscalls/cacheflush/cacheflush01.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */+#if defined(__arm__)
TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr + getpagesize(),0));
if (TEST_RETURN == 0) {tst_resm(TPASS, "passed with no errno");} else {tst_resm(TFAIL, "failed with unexpected errno");}+#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(), ICACHE)); if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno"); @@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();-- 1.7.9.5
-- You received this message because you are subscribed to the Google
Groups
"Linaro Networking" group. To unsubscribe from this group and stop receiving emails from it, send
an
email to linaro-networking+unsubscribe@linaro.orgmailto:linaro-networking%2Bunsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.orgmailto:linaro-networking@linaro.org.
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
linaro-kernel mailing list linaro-kernel@lists.linaro.orgmailto:linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
_______________________________________________ linaro-kernel mailing list linaro-kernel@lists.linaro.orgmailto:linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Vladimir thanks for your explanation. Since the purpose is to work with the I-cache, this function is more targeted towards JIT compilers and similar code that load or generate instructions directly to memory. The access through the direct call to kernel address space seems efficient.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Vladimir Murzin [mailto:murzin.v@gmail.com] Sent: 04 October 2013 17:26 To: Maxim Uvarov Cc: Ola Liljedahl; linaro-networking@linaro.org; linaro- kernel@lists.linaro.org; patches@linaro.org Subject: Re: [LNG] [PATCH] LTP cacheflush01 add arm variant
On Fri, Oct 04, 2013 at 06:43:12PM +0400, Maxim Uvarov wrote:
On 10/04/2013 06:04 PM, Ola Liljedahl wrote:
From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 04 October 2013 13:44 To: Ola Liljedahl Cc: linaro-networking@linaro.org; patches@linaro.org; linaro- kernel@lists.linaro.org Subject: Re: [LNG] [PATCH] LTP cacheflush01 add arm variant
On 10/04/2013 03:13 PM, Ola Liljedahl wrote:
What's the overhead of a system call compared to the cost of the
actual
flush operation? Why are you asking about that? There should be some overhead but I
don't
think that somebody measured it.
[Ola] Because system calls are expensive and if we are only going to
flush/invalidate
a small amount of data but rather frequently (e.g. packet buffers in
the days of
incoherent I/O devices), doing this operation through a system call
would degrade
performance. This did look like a Linux system call.
What's the expected use case (specifically number of bytes flushed)
of
this call? (Maybe this is completely out of our control). Well, it calls:
flush_cache_user_range(start, end);
coherent_user_range
- v7_coherent_user_range(start,end)
- Ensure that the I and D caches are coherent within specified
- region. This is typically used when code has been written to
- a memory region, and will be executed.
[Ola] Flush cache is a poor name for this call that merely assures
synchronisation
between I and D-caches (because instructions have been written by the
application
and should later be executed).
- start - virtual start address of region
- end - virtual end address of region
-EFAULT - virt address not mapped, -EINVAL - wrong start/end arguments, 0 - on success.
Original (mips only I suppose) test does not do any invalid parameters check. So I just added only right case.
This is a flush (and invalidate) operation, not a true invalidate
operation I assume, so it could be performed completely in user space,
no
supervisor privileges required. Is a user space implementation (using
a
DSO) contemplated? Did not understand that. What is "user space implementation using DSO"
?
[Ola] I meant vDSO. A kernel call actually implemented in user space
using a
shared object. This to avoid the overhead of trapping in and out of the
kernel
which could be substantial compared to the cost of flushing and
invalidating
a few cache lines in the I- and D-caches. That's why I ask about
typical usage.
Would this system call be called from e.g. JIT compilers?
A true invalidate operation (no writeback of dirty cache lines, any
modified
data would get lost) is more dangerous and are probably not allowed to
be
performed from user space. But the need for such an operation is
negligible.
-- Ola
I don't really know where and how this syscall is used. I think it might be gdb or some applications with executable code to malloced area. Because of
original
problem was to fix 'there is no such syscall _NR_cacheflush' in testcases/kernel/syscalls/cachflush test. I.e. test is under syscall directory it has to be syscall.
And the other question is how it's better to use cacheflush with smaller overhead.
Also I do not see any user space include file for cacheflush(). arm-linux-gnueabihf- does not know how to compile it. So I still don't understand how to use cache flush with vDSO. Is it already implemented or it's just idea to do?
Sorry for stepping into your discussion. Just a bit info about cacheslush and friends...
AFAIK discussed syscall is hidden for arm. It means it is not supposed to be called explicitly. Despite it is syscall it is called indirectly via gcc's built-in function: void __builtin___clear_cache (char *begin, char *end)
Short info from [1]:
This function is usead to flush the processor's instruction cache for the region of memory between begin inclusive and end exclusive. Some targets require that the instruction cache be flushed, after modifying memory containing code, in order to obtain deterministic behavior. If the target does not require instruction cache flushes, __builtin___clear_cache has no effect. Otherwise either instructions are emitted in-line to clear the instruction cache or a call to the __clear_cache function in libgcc is made.
Simple testcase
int main(void) { __builtin___clear_cache(0, 0); return 0; }
will be generated by gcc into
00000000 <main>: 0: b580 push {r7, lr} 2: af00 add r7, sp, #0 4: 2000 movs r0, #0 6: 2100 movs r1, #0 8: f7ff fffe bl 0 <__clear_cache> c: 2300 movs r3, #0 e: 4618 mov r0, r3 10: bd80 pop {r7, pc} 12: bf00 nop
You can see that "call" is just branch to kernel space address, something like vDSO (called kernel helpers in ARM Linux terminology [2]). So, it is optimized for user space.
In my opinion, LTP test in question is not applicable for ARM - it tests nothing. It'd be better to test that clear_cache do its job.
[1] http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html [2] linux/Documentation/arm/kernel_user_helpers.txt
Thanks Vladimir
Maxim.
Thank you, Maxim.
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org] Sent: 03 October 2013 14:08 To: linaro-networking@linaro.org Cc: patches@linaro.org; linaro-kernel@lists.linaro.org; Maxim Uvarov Subject: [LNG] [PATCH] LTP cacheflush01 add arm variant
Cache flush on arm provided via __ARM_NR_cacheflush(unsigned long start, unsigned long end, int
flags)
defined in ./arch/arm/kernel/traps.c. Flags are not used, providing 0 there.
Signed-off-by: Maxim Uvarov maxim.uvarov@linaro.com
.../kernel/syscalls/cacheflush/cacheflush01.c | 9
+++++++++
1 file changed, 9 insertions(+)
diff --git a/testcases/kernel/syscalls/cacheflush/cacheflush01.c b/testcases/kernel/syscalls/cacheflush/cacheflush01.c index 9c02f0a..fae51b4 100644 --- a/testcases/kernel/syscalls/cacheflush/cacheflush01.c +++ b/testcases/kernel/syscalls/cacheflush/cacheflush01.c @@ -137,6 +137,14 @@ int main(int ac, char **av) }
/* Invokes cacheflush() with proper parameters */+#if defined(__arm__)
TEST(ltp_syscall(__ARM_NR_cacheflush, addr, addr +getpagesize(),
0));
if (TEST_RETURN == 0) {tst_resm(TPASS, "passed with no errno");} else {tst_resm(TFAIL, "failed with unexpected errno");}+#else TEST(ltp_syscall(__NR_cacheflush, addr, getpagesize(),
ICACHE));
if (TEST_RETURN == 0) { tst_resm(TPASS, "passed with no errno");@@ -157,6 +165,7 @@ int main(int ac, char **av) } else { tst_resm(TFAIL, "failed with unexpected errno"); } +#endif
cleanup(); tst_exit();-- 1.7.9.5
-- You received this message because you are subscribed to the Google
Groups
"Linaro Networking" group. To unsubscribe from this group and stop receiving emails from it,
send
an
email to linaro-networking+unsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.org.
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose
the
contents to any other person, use it for any purpose, or store or copy
the
information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ,
Registered in England & Wales, Company No: 2548782
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
linaro-kernel@lists.linaro.org
-
Maxim Uvarov -
Mike Holmes -
Ola Liljedahl -
Vladimir Murzin