some questions about kernel source
Dear all: I have some questions about kernel source code: 1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter? 2. what are below __releases and __acquires used for? ehci_urb_done(struct ehci_hcd *ehci, struct urb *urb, int status) __releases(ehci->lock) __acquires(ehci->lock) these 2 cmds are not in the {}, so I guess it will not compile out machine. If so, why we add them after function prototype? -- Regards,
Hello loody,
1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter?
Yes, it is a hint to the compiler that the parameter is mostly read, thus if the compiler has to make a decision between optimizing one of the read / write paths, it will optimize the read path even at the expense of write path.
2. what are below __releases and __acquires used for? ehci_urb_done(struct ehci_hcd *ehci, struct urb *urb, int status) __releases(ehci->lock) __acquires(ehci->lock) these 2 cmds are not in the {}, so I guess it will not compile out machine. If so, why we add them after function prototype?
I think it is some jugglery to aid the compiler and intelligent static code analysis tools to inform this function acquires and releases the said lock. This would help those tools in finding out potential synchronization issues, lockup scenarios. Thanks, Rajat
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies- bounces@kernelnewbies.org] On Behalf Of loody Sent: Wednesday, February 16, 2011 11:23 AM To: kernelnewbies@kernelnewbies.org Subject: some questions about kernel source
Dear all: I have some questions about kernel source code: 1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter? 2. what are below __releases and __acquires used for? ehci_urb_done(struct ehci_hcd *ehci, struct urb *urb, int status) __releases(ehci->lock) __acquires(ehci->lock) these 2 cmds are not in the {}, so I guess it will not compile out machine. If so, why we add them after function prototype?
-- Regards,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi :) On Wed, Feb 16, 2011 at 12:59, Rajat Jain <rajatjain@juniper.net> wrote:
Hello loody,
1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter?
Yes, it is a hint to the compiler that the parameter is mostly read, thus if the compiler has to make a decision between optimizing one of the read / write paths, it will optimize the read path even at the expense of write path.
To be precise, they will be grouped into same cache line as much as possible. By doing so, those cache line won't be invalidated so often (keeping them "hot" :) hehehhe ) -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
hi :-) 2011/2/16 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi :)
On Wed, Feb 16, 2011 at 12:59, Rajat Jain <rajatjain@juniper.net> wrote:
Hello loody,
1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter?
Yes, it is a hint to the compiler that the parameter is mostly read, thus if the compiler has to make a decision between optimizing one of the read / write paths, it will optimize the read path even at the expense of write path.
To be precise, they will be grouped into same cache line as much as possible. By doing so, those cache line won't be invalidated so often (keeping them "hot" :) hehehhe )
I cannot find it on the gcc manual. is it a option in kernel for kernel usage? if so, where I can found them. If not, can I use it on normal user level program? BTW, i have some more questions (since it is also related to kernel, I append in the same mail) 1. the parameters we pass to ftrace_trace_function are (unsigned long ip, unsigned long parent_ip), which are previous and pre-previous return address. what can we do on these 2 addresses? 2. per kernel document, HAVE_FUNCTION_TRACE_MCOUNT_TEST is used for " an optional optimization for the normal case" and there is a pseudo sample code such as + if (function_trace_stop) + return; so the optimization the config did is judge whether "function_trace_stop" before operation, right? Meanwhile, I found this judgement seems enable in ftrace_test_stop_func and it is located at #ifndef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST. The source code seems quite conflict with the document. -- Appreciate your kind help, miloody
On Thu, Feb 17, 2011 at 9:17 AM, loody <miloody@gmail.com> wrote:
hi :-)
2011/2/16 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi :)
On Wed, Feb 16, 2011 at 12:59, Rajat Jain <rajatjain@juniper.net> wrote:
Hello loody,
1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter?
Yes, it is a hint to the compiler that the parameter is mostly read, thus if the compiler has to make a decision between optimizing one of the read / write paths, it will optimize the read path even at the expense of write path.
To be precise, they will be grouped into same cache line as much as possible. By doing so, those cache line won't be invalidated so often (keeping them "hot" :) hehehhe )
I cannot find it on the gcc manual. is it a option in kernel for kernel usage? if so, where I can found them. If not, can I use it on normal user level program?
It is a macro defined for x86 as: #define __read_mostly __attribute__((__section__(".data..read_mostly"))) http://lxr.linux.no/linux+v2.6.37/arch/x86/include/asm/cache.h ---snip--- Start a new thread for a new topic. -- John
hi : 2011/2/18 John Mahoney <jmahoney@waav.com>:
On Thu, Feb 17, 2011 at 9:17 AM, loody <miloody@gmail.com> wrote:
hi :-)
2011/2/16 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi :)
On Wed, Feb 16, 2011 at 12:59, Rajat Jain <rajatjain@juniper.net> wrote:
Hello loody,
1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter?
Yes, it is a hint to the compiler that the parameter is mostly read, thus if the compiler has to make a decision between optimizing one of the read / write paths, it will optimize the read path even at the expense of write path.
To be precise, they will be grouped into same cache line as much as possible. By doing so, those cache line won't be invalidated so often (keeping them "hot" :) hehehhe )
I cannot find it on the gcc manual. is it a option in kernel for kernel usage? if so, where I can found them. If not, can I use it on normal user level program?
It is a macro defined for x86 as:
#define __read_mostly __attribute__((__section__(".data..read_mostly")))
http://lxr.linux.no/linux+v2.6.37/arch/x86/include/asm/cache.h I found where you pointed out but I try to find out where is it in the mips arch. thank you, miloody
On Fri, Feb 18, 2011 at 9:28 AM, loody <miloody@gmail.com> wrote:
hi :
2011/2/18 John Mahoney <jmahoney@waav.com>:
On Thu, Feb 17, 2011 at 9:17 AM, loody <miloody@gmail.com> wrote:
hi :-)
2011/2/16 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi :)
On Wed, Feb 16, 2011 at 12:59, Rajat Jain <rajatjain@juniper.net> wrote:
Hello loody,
1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter?
Yes, it is a hint to the compiler that the parameter is mostly read, thus if the compiler has to make a decision between optimizing one of the read / write paths, it will optimize the read path even at the expense of write path.
To be precise, they will be grouped into same cache line as much as possible. By doing so, those cache line won't be invalidated so often (keeping them "hot" :) hehehhe )
I cannot find it on the gcc manual. is it a option in kernel for kernel usage? if so, where I can found them. If not, can I use it on normal user level program?
It is a macro defined for x86 as:
#define __read_mostly __attribute__((__section__(".data..read_mostly")))
http://lxr.linux.no/linux+v2.6.37/arch/x86/include/asm/cache.h I found where you pointed out but I try to find out where is it in the mips arch.
It looks pretty new for mips and you may have older code. $ git log -p cache.h commit 1befdd5536e1500371f7f884d0f0ae528a519333 Author: David Daney <ddaney@caviumnetworks.com> Date: Thu Oct 14 12:36:49 2010 -0700 MIPS: Implement __read_mostly commit 1befdd5536e1500371f7f884d0f0ae528a519333 Author: David Daney <ddaney@caviumnetworks.com> Date: Thu Oct 14 12:36:49 2010 -0700 MIPS: Implement __read_mostly Just do what everyone else is doing by placing __read_mostly things in the .data.read_mostly section. mips_io_port_base can not be read-only (const) and writable (__read_mostly) at the same time. One of them has to go, so I chose to eliminate the __read_mostly. It will still get stuck in a portion of memory that is not adjacent to things that are written, and thus not be on a dirty cache line, for whatever that is worth. Signed-off-by: David Daney <ddaney@caviumnetworks.com> To: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/1702/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> As a side note I would not use this just because you think your variable is read more than written. Premature optimization is a waste of time, so make sure your on a hot path before even considering something like this. -- John
On Fri, Feb 18, 2011 at 12:16 PM, John Mahoney <jmahoney@waav.com> wrote:
On Fri, Feb 18, 2011 at 9:28 AM, loody <miloody@gmail.com> wrote:
hi :
2011/2/18 John Mahoney <jmahoney@waav.com>:
On Thu, Feb 17, 2011 at 9:17 AM, loody <miloody@gmail.com> wrote:
hi :-)
2011/2/16 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi :)
On Wed, Feb 16, 2011 at 12:59, Rajat Jain <rajatjain@juniper.net> wrote:
Hello loody,
1. in kernel/trace, I always see "__read_mostly" at the end of parameter is that a compiler optimization parameter?
Yes, it is a hint to the compiler that the parameter is mostly read, thus if the compiler has to make a decision between optimizing one of the read / write paths, it will optimize the read path even at the expense of write path.
To be precise, they will be grouped into same cache line as much as possible. By doing so, those cache line won't be invalidated so often (keeping them "hot" :) hehehhe )
I cannot find it on the gcc manual. is it a option in kernel for kernel usage? if so, where I can found them. If not, can I use it on normal user level program?
It is a macro defined for x86 as:
#define __read_mostly __attribute__((__section__(".data..read_mostly")))
http://lxr.linux.no/linux+v2.6.37/arch/x86/include/asm/cache.h I found where you pointed out but I try to find out where is it in the mips arch.
It looks pretty new for mips and you may have older code.
$ git log -p cache.h commit 1befdd5536e1500371f7f884d0f0ae528a519333 Author: David Daney <ddaney@caviumnetworks.com> Date: Thu Oct 14 12:36:49 2010 -0700
MIPS: Implement __read_mostly commit 1befdd5536e1500371f7f884d0f0ae528a519333 Author: David Daney <ddaney@caviumnetworks.com> Date: Thu Oct 14 12:36:49 2010 -0700
MIPS: Implement __read_mostly
Just do what everyone else is doing by placing __read_mostly things in the .data.read_mostly section.
mips_io_port_base can not be read-only (const) and writable (__read_mostly) at the same time. One of them has to go, so I chose to eliminate the __read_mostly. It will still get stuck in a portion of memory that is not adjacent to things that are written, and thus not be on a dirty cache line, for whatever that is worth.
Signed-off-by: David Daney <ddaney@caviumnetworks.com> To: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/1702/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
I left off some the end see below. diff --git a/arch/mips/include/asm/cache.h b/arch/mips/include/asm/cache.h index 37f175c..650ac9b 100644 --- a/arch/mips/include/asm/cache.h +++ b/arch/mips/include/asm/cache.h @@ -17,4 +17,6 @@ #define SMP_CACHE_SHIFT L1_CACHE_SHIFT #define SMP_CACHE_BYTES L1_CACHE_BYTES +#define __read_mostly __attribute__((__section__(".data.read_mostly"))) + #endif /* _ASM_CACHE_H */
participants (4)
-
John Mahoney -
loody -
Mulyadi Santosa -
Rajat Jain