On Wed, 27 Nov 2013 17:13:08 +0100
Ingo Molnar wrote:
>
> * Steven Rostedt wrote:
>
> > On Wed, 27 Nov 2013 16:46:00 +0100
> > Ingo Molnar wrote:
> >
> > >
> > > * Peter Zijlstra wrote:
> > >
> > > > On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
> > > > > So why does GCC
On 11/27, Peter Zijlstra wrote:
>
> Anyway, yes GCC seems to behave as we 'expect' it to; I just can't find
> the language spec actually guaranteeing this.
And the kernel already assumes that gcc should do this, for example
struct siginfo info = {};
in do_tkill().
(this initialization
* Steven Rostedt wrote:
> On Wed, 27 Nov 2013 16:46:00 +0100
> Ingo Molnar wrote:
>
> >
> > * Peter Zijlstra wrote:
> >
> > > On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
> > > > So why does GCC then behave like this:
> > >
> > > I think because its a much saner behaviour;
On Wed, 27 Nov 2013 10:56:16 -0500
Steven Rostedt wrote:
> On Wed, 27 Nov 2013 16:46:00 +0100
> Ingo Molnar wrote:
> > So from C99 standard §6.7.8 (Initialization)/21:
> >
> > "If there are fewer initializers in a brace-enclosed list than
> > there are elements or members of an
On Wed, Nov 27, 2013 at 10:56:16AM -0500, Steven Rostedt wrote:
> > So from C99 standard §6.7.8 (Initialization)/21:
> >
> > "If there are fewer initializers in a brace-enclosed list than
> > there are elements or members of an aggregate, or fewer characters
> > in a string literal used
On Wed, Nov 27, 2013 at 04:46:00PM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
> > > So why does GCC then behave like this:
> >
> > I think because its a much saner behaviour; also it might still be the
> > spec
On Wed, 27 Nov 2013 16:46:00 +0100
Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
> > > So why does GCC then behave like this:
> >
> > I think because its a much saner behaviour; also it might still be the
> > spec actually
* Peter Zijlstra wrote:
> On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
> > So why does GCC then behave like this:
>
> I think because its a much saner behaviour; also it might still be the
> spec actually says this, its a somewhat opaque text.
>
> Anyway, yes GCC seems to
and even this works:
triton:~> cat test.c
struct foo {
int a;
int b;
};
int litter_our_stack(void)
{
volatile struct foo x = { .a = 1, .b = 2 };
return x.b;
}
int test_code(void)
{
volatile struct foo x = { .a = 1, /* .b not initialized explicitly */
On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
> So why does GCC then behave like this:
I think because its a much saner behaviour; also it might still be the
spec actually says this, its a somewhat opaque text.
Anyway, yes GCC seems to behave as we 'expect' it to; I just can't
* Peter Zijlstra wrote:
> On Wed, Nov 27, 2013 at 03:34:35PM +0100, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
> > > > On Wed, 27 Nov 2013 14:43:45 +0100
> > > > Juri Lelli wrote:
> > > > diff --git
On Wed, 27 Nov 2013 15:26:49 +0100
Peter Zijlstra wrote:
> On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
> > On Wed, 27 Nov 2013 14:43:45 +0100
> > Juri Lelli wrote:
> > diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
> > > index f76f8d6..ad94604
On Wed, Nov 27, 2013 at 03:34:35PM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
> > > On Wed, 27 Nov 2013 14:43:45 +0100
> > > Juri Lelli wrote:
> > > diff --git a/kernel/trace/trace_selftest.c
* Peter Zijlstra wrote:
> On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
> > On Wed, 27 Nov 2013 14:43:45 +0100
> > Juri Lelli wrote:
> > diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
> > > index f76f8d6..ad94604 100644
> > > ---
On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
> On Wed, 27 Nov 2013 14:43:45 +0100
> Juri Lelli wrote:
> diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
> > index f76f8d6..ad94604 100644
> > --- a/kernel/trace/trace_selftest.c
> > +++
On 11/27/2013 03:16 PM, Steven Rostedt wrote:
> On Wed, 27 Nov 2013 14:43:45 +0100
> Juri Lelli wrote:
> diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
>> index f76f8d6..ad94604 100644
>> --- a/kernel/trace/trace_selftest.c
>> +++ b/kernel/trace/trace_selftest.c
>> @@
On Wed, 27 Nov 2013 14:43:45 +0100
Juri Lelli wrote:
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
> index f76f8d6..ad94604 100644
> --- a/kernel/trace/trace_selftest.c
> +++ b/kernel/trace/trace_selftest.c
> @@ -1023,16 +1023,16 @@ trace_selftest_startup_nop(struct
On 11/20/2013 10:33 PM, Steven Rostedt wrote:
> On Thu, 7 Nov 2013 14:43:42 +0100
> Juri Lelli wrote:
>
>
>> +/*
>> + * Semantic is like this:
>> + * - wakeup tracer handles all tasks in the system, independently
>> + *from their scheduling class;
>> + * - wakeup_rt
On 11/20/2013 10:33 PM, Steven Rostedt wrote:
On Thu, 7 Nov 2013 14:43:42 +0100
Juri Lelli juri.le...@gmail.com wrote:
+/*
+ * Semantic is like this:
+ * - wakeup tracer handles all tasks in the system, independently
+ *from their scheduling class;
+ * -
On Wed, 27 Nov 2013 14:43:45 +0100
Juri Lelli juri.le...@gmail.com wrote:
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index f76f8d6..ad94604 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -1023,16 +1023,16 @@
On 11/27/2013 03:16 PM, Steven Rostedt wrote:
On Wed, 27 Nov 2013 14:43:45 +0100
Juri Lelli juri.le...@gmail.com wrote:
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index f76f8d6..ad94604 100644
--- a/kernel/trace/trace_selftest.c
+++
On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
On Wed, 27 Nov 2013 14:43:45 +0100
Juri Lelli juri.le...@gmail.com wrote:
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index f76f8d6..ad94604 100644
--- a/kernel/trace/trace_selftest.c
+++
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
On Wed, 27 Nov 2013 14:43:45 +0100
Juri Lelli juri.le...@gmail.com wrote:
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index f76f8d6..ad94604
On Wed, Nov 27, 2013 at 03:34:35PM +0100, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
On Wed, 27 Nov 2013 14:43:45 +0100
Juri Lelli juri.le...@gmail.com wrote:
diff --git
On Wed, 27 Nov 2013 15:26:49 +0100
Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
On Wed, 27 Nov 2013 14:43:45 +0100
Juri Lelli juri.le...@gmail.com wrote:
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 03:34:35PM +0100, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 09:16:47AM -0500, Steven Rostedt wrote:
On Wed, 27 Nov 2013 14:43:45 +0100
Juri Lelli
On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
So why does GCC then behave like this:
I think because its a much saner behaviour; also it might still be the
spec actually says this, its a somewhat opaque text.
Anyway, yes GCC seems to behave as we 'expect' it to; I just can't find
and even this works:
triton:~ cat test.c
struct foo {
int a;
int b;
};
int litter_our_stack(void)
{
volatile struct foo x = { .a = 1, .b = 2 };
return x.b;
}
int test_code(void)
{
volatile struct foo x = { .a = 1, /* .b not initialized explicitly */ };
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
So why does GCC then behave like this:
I think because its a much saner behaviour; also it might still be the
spec actually says this, its a somewhat opaque text.
Anyway, yes GCC
On Wed, 27 Nov 2013 16:46:00 +0100
Ingo Molnar mi...@kernel.org wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
So why does GCC then behave like this:
I think because its a much saner behaviour; also it might still be
On Wed, Nov 27, 2013 at 04:46:00PM +0100, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
So why does GCC then behave like this:
I think because its a much saner behaviour; also it might still be the
spec
On Wed, Nov 27, 2013 at 10:56:16AM -0500, Steven Rostedt wrote:
So from C99 standard §6.7.8 (Initialization)/21:
If there are fewer initializers in a brace-enclosed list than
there are elements or members of an aggregate, or fewer characters
in a string literal used to
On Wed, 27 Nov 2013 10:56:16 -0500
Steven Rostedt rost...@goodmis.org wrote:
On Wed, 27 Nov 2013 16:46:00 +0100
Ingo Molnar mi...@kernel.org wrote:
So from C99 standard §6.7.8 (Initialization)/21:
If there are fewer initializers in a brace-enclosed list than
there are elements
* Steven Rostedt rost...@goodmis.org wrote:
On Wed, 27 Nov 2013 16:46:00 +0100
Ingo Molnar mi...@kernel.org wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 04:35:19PM +0100, Ingo Molnar wrote:
So why does GCC then behave like this:
I think
On 11/27, Peter Zijlstra wrote:
Anyway, yes GCC seems to behave as we 'expect' it to; I just can't find
the language spec actually guaranteeing this.
And the kernel already assumes that gcc should do this, for example
struct siginfo info = {};
in do_tkill().
(this initialization
On Wed, 27 Nov 2013 17:13:08 +0100
Ingo Molnar mi...@kernel.org wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Wed, 27 Nov 2013 16:46:00 +0100
Ingo Molnar mi...@kernel.org wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Nov 27, 2013 at 04:35:19PM
On Thu, 7 Nov 2013 14:43:42 +0100
Juri Lelli wrote:
> + /*
> + * Semantic is like this:
> + * - wakeup tracer handles all tasks in the system, independently
> + *from their scheduling class;
> + * - wakeup_rt tracer handles tasks belonging to sched_dl and
> +
On Thu, 7 Nov 2013 14:43:42 +0100
Juri Lelli juri.le...@gmail.com wrote:
+ /*
+ * Semantic is like this:
+ * - wakeup tracer handles all tasks in the system, independently
+ *from their scheduling class;
+ * - wakeup_rt tracer handles tasks belonging to
From: Dario Faggioli
It is very likely that systems that wants/needs to use the new
SCHED_DEADLINE policy also want to have the scheduling latency of
the -deadline tasks under control.
For this reason a new version of the scheduling wakeup latency,
called "wakeup_dl", is introduced.
As a
From: Dario Faggioli raist...@linux.it
It is very likely that systems that wants/needs to use the new
SCHED_DEADLINE policy also want to have the scheduling latency of
the -deadline tasks under control.
For this reason a new version of the scheduling wakeup latency,
called wakeup_dl, is
From: Dario Faggioli
It is very likely that systems that wants/needs to use the new
SCHED_DEADLINE policy also want to have the scheduling latency of
the -deadline tasks under control.
For this reason a new version of the scheduling wakeup latency,
called "wakeup_dl", is introduced.
As a
From: Dario Faggioli raist...@linux.it
It is very likely that systems that wants/needs to use the new
SCHED_DEADLINE policy also want to have the scheduling latency of
the -deadline tasks under control.
For this reason a new version of the scheduling wakeup latency,
called wakeup_dl, is
From: Dario Faggioli
It is very likely that systems that wants/needs to use the new
SCHED_DEADLINE policy also want to have the scheduling latency of
the -deadline tasks under control.
For this reason a new version of the scheduling wakeup latency,
called "wakeup_dl", is introduced.
As a
From: Dario Faggioli raist...@linux.it
It is very likely that systems that wants/needs to use the new
SCHED_DEADLINE policy also want to have the scheduling latency of
the -deadline tasks under control.
For this reason a new version of the scheduling wakeup latency,
called wakeup_dl, is
44 matches
Mail list logo