| Message ID | 1380802059-7977-1-git-send-email-maxim.uvarov@linaro.com |
|---|---|
| State | New |
| Headers | show |
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 >
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
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.com<mailto: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<mailto:maxim.uvarov@linaro.org>] > >> Sent: 04 October 2013 13:44 > >> To: Ola Liljedahl > >> Cc: linaro-networking@linaro.org<mailto:linaro-networking@linaro.org>; patches@linaro.org<mailto:patches@linaro.org>; linaro- > >> kernel@lists.linaro.org<mailto: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<tel:%2B46%20706%20866%20373> Skype: ola.liljedahl > >>> > >>> > >>>> -----Original Message----- > >>>> From: Maxim Uvarov [mailto:maxim.uvarov@linaro.org<mailto:maxim.uvarov@linaro.org>] > >>>> Sent: 03 October 2013 14:08 > >>>> To: linaro-networking@linaro.org<mailto:linaro-networking@linaro.org> > >>>> Cc: patches@linaro.org<mailto:patches@linaro.org>; linaro-kernel@lists.linaro.org<mailto: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<mailto: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<mailto:linaro-networking%2Bunsubscribe@linaro.org>. > >>>> To post to this group, send email to linaro-networking@linaro.org<mailto: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<mailto:linaro-kernel@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/linaro-kernel
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();
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(+)