* Adrian Bunk ([EMAIL PROTECTED]) wrote:
> On Wed, Jun 20, 2007 at 05:59:27PM -0400, Mathieu Desnoyers wrote:
> > * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > > On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
> > > >...
> > > > Well, we must take into account where these markers
On Wed, Jun 20, 2007 at 05:59:27PM -0400, Mathieu Desnoyers wrote:
> * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
> > >...
> > > Well, we must take into account where these markers are added and how
> > > often the marked code is
On Wed, Jun 20, 2007 at 05:59:27PM -0400, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
...
Well, we must take into account where these markers are added and how
often the marked code is run. Since I
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Wed, Jun 20, 2007 at 05:59:27PM -0400, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
...
Well, we must take into account where these markers are added and
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
> On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
> >...
> > Well, we must take into account where these markers are added and how
> > often the marked code is run. Since I mark very highly used code paths
> > (interrupt handlers, page
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
...
Well, we must take into account where these markers are added and how
often the marked code is run. Since I mark very highly used code paths
(interrupt handlers, page faults,
On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
>...
> Well, we must take into account where these markers are added and how
> often the marked code is run. Since I mark very highly used code paths
> (interrupt handlers, page faults, lockdep code) and also plan to mark
> other
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
> On Wed, Jun 13, 2007 at 11:57:24AM -0400, Mathieu Desnoyers wrote:
> > Hi Adrian,
>
> Hi Mathieu,
>
> >...
> > > 2. What is the real-life performance improvement?
> > > That micro benchmarks comparing cache hits with cache misses give great
> > >
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Wed, Jun 13, 2007 at 11:57:24AM -0400, Mathieu Desnoyers wrote:
Hi Adrian,
Hi Mathieu,
...
2. What is the real-life performance improvement?
That micro benchmarks comparing cache hits with cache misses give great
looking numbers is
On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
...
Well, we must take into account where these markers are added and how
often the marked code is run. Since I mark very highly used code paths
(interrupt handlers, page faults, lockdep code) and also plan to mark
other code
On Wed, Jun 13, 2007 at 11:57:24AM -0400, Mathieu Desnoyers wrote:
> Hi Adrian,
Hi Mathieu,
>...
> > 2. What is the real-life performance improvement?
> > That micro benchmarks comparing cache hits with cache misses give great
> > looking numbers is obvious.
> > But what will be the performance
Hi Adrian,
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
> I have two questions for getting the bigger picture:
>
> 1. How much code will be changed?
> Looking at the F00F bug fixup example, it seems we'll have to make
> several functions in every single driver conditional in the kernel for
> getting
Hi Adrian,
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
I have two questions for getting the bigger picture:
1. How much code will be changed?
Looking at the F00F bug fixup example, it seems we'll have to make
several functions in every single driver conditional in the kernel for
getting the
On Wed, Jun 13, 2007 at 11:57:24AM -0400, Mathieu Desnoyers wrote:
Hi Adrian,
Hi Mathieu,
...
2. What is the real-life performance improvement?
That micro benchmarks comparing cache hits with cache misses give great
looking numbers is obvious.
But what will be the performance
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
>
> > +struct __cond_call_struct {
>
> Calling structs *_struct is severly deprecated and will cause some people
> to make fun of your code.
>
ok
>
> > + const char *name;
> > + void *enable;
> > +
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
+struct __cond_call_struct {
Calling structs *_struct is severly deprecated and will cause some people
to make fun of your code.
ok
+ const char *name;
+ void *enable;
+ int flags;
+}
On Wed, May 30, 2007 at 10:00:26AM -0400, Mathieu Desnoyers wrote:
> Conditional calls are used to compile in code that is meant to be dynamically
> enabled at runtime. When code is disabled, it has a very small footprint.
>
> It has a generic cond_call version and optimized per architecture
On Wed, May 30, 2007 at 10:00:26AM -0400, Mathieu Desnoyers wrote:
Conditional calls are used to compile in code that is meant to be dynamically
enabled at runtime. When code is disabled, it has a very small footprint.
It has a generic cond_call version and optimized per architecture
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> > +#ifdef CONFIG_COND_CALL_ENABLE_OPTIMIZATION
> > +#include /* optimized cond_call flavor */
> > +#else
> > +#include /* fallback on generic cond_call */
> > +#endif
>
> The preferred way to do this is to give every architecture an
>
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> +struct __cond_call_struct {
Calling structs *_struct is severly deprecated and will cause some people
to make fun of your code.
> + const char *name;
> + void *enable;
> + int flags;
> +} __attribute__((packed));
The packed doesn't
Mathieu Desnoyers [EMAIL PROTECTED] writes:
+struct __cond_call_struct {
Calling structs *_struct is severly deprecated and will cause some people
to make fun of your code.
+ const char *name;
+ void *enable;
+ int flags;
+} __attribute__((packed));
The packed doesn't seem to
* Andrew Morton ([EMAIL PROTECTED]) wrote:
+#ifdef CONFIG_COND_CALL_ENABLE_OPTIMIZATION
+#include asm/condcall.h /* optimized cond_call flavor */
+#else
+#include asm-generic/condcall.h /* fallback on generic cond_call */
+#endif
The preferred way to do this is to give every
On Wed, 30 May 2007 10:00:26 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Conditional calls are used to compile in code that is meant to be dynamically
> enabled at runtime. When code is disabled, it has a very small footprint.
>
> It has a generic cond_call version and optimized per
On Wed, 30 May 2007 10:00:26 -0400
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
Conditional calls are used to compile in code that is meant to be dynamically
enabled at runtime. When code is disabled, it has a very small footprint.
It has a generic cond_call version and optimized per
24 matches
Mail list logo
