* Colin Fowler <[EMAIL PROTECTED]> wrote:
> > there are a handful of 'scheduler feature bits' in
> > /proc/sys/kernel/sched_features:
> >
> > enum {
> > SCHED_FEAT_NEW_FAIR_SLEEPERS= 1,
> > SCHED_FEAT_WAKEUP_PREEMPT = 2,
> > SCHED_FEAT_START_DEBIT = 4,
* Colin Fowler [EMAIL PROTECTED] wrote:
there are a handful of 'scheduler feature bits' in
/proc/sys/kernel/sched_features:
enum {
SCHED_FEAT_NEW_FAIR_SLEEPERS= 1,
SCHED_FEAT_WAKEUP_PREEMPT = 2,
SCHED_FEAT_START_DEBIT = 4,
> there are a handful of 'scheduler feature bits' in
> /proc/sys/kernel/sched_features:
>
> enum {
> SCHED_FEAT_NEW_FAIR_SLEEPERS= 1,
> SCHED_FEAT_WAKEUP_PREEMPT = 2,
> SCHED_FEAT_START_DEBIT = 4,
> SCHED_FEAT_TREE_AVG = 8,
>
Hi Ingo,
I have permission for a binary only release (mailed the supervisor
intermediately after your earler mail). I'm sure the abstract code
simulating the workload will be alright too, but I need time to put it
together as I'm a bit swamped at the moment. Will hope to have it in
the next few
* Colin Fowler <[EMAIL PROTECTED]> wrote:
> Hi Ingo, I'll need to convince my supervisor first if I can release a
> binary. Technically anythin glike this needs to go through our
> University's "innovations department" and requires lengthy paperwork
> and NDAs :(.
a binary wouldnt work for
Hi Ingo, I'll need to convince my supervisor first if I can release a
binary. Technically anythin glike this needs to go through our
University's "innovations department" and requires lengthy paperwork
and NDAs :(.
regards,
Colin
On Jan 16, 2008 3:35 PM, Ingo Molnar <[EMAIL PROTECTED]>
* Colin Fowler <[EMAIL PROTECTED]> wrote:
> > and context-switches 45K times a second. Do you know what is going
> > on there? I thought ray-tracing is something that can be
> > parallelized pretty efficiently, without having to contend and
> > schedule too much.
>
> This is a RTRT
* Colin Fowler [EMAIL PROTECTED] wrote:
and context-switches 45K times a second. Do you know what is going
on there? I thought ray-tracing is something that can be
parallelized pretty efficiently, without having to contend and
schedule too much.
This is a RTRT (real-time ray
Hi Ingo, I'll need to convince my supervisor first if I can release a
binary. Technically anythin glike this needs to go through our
University's innovations department and requires lengthy paperwork
and NDAs :(.
regards,
Colin
On Jan 16, 2008 3:35 PM, Ingo Molnar [EMAIL PROTECTED]
* Colin Fowler [EMAIL PROTECTED] wrote:
Hi Ingo, I'll need to convince my supervisor first if I can release a
binary. Technically anythin glike this needs to go through our
University's innovations department and requires lengthy paperwork
and NDAs :(.
a binary wouldnt work for me
Hi Ingo,
I have permission for a binary only release (mailed the supervisor
intermediately after your earler mail). I'm sure the abstract code
simulating the workload will be alright too, but I need time to put it
together as I'm a bit swamped at the moment. Will hope to have it in
the next few
there are a handful of 'scheduler feature bits' in
/proc/sys/kernel/sched_features:
enum {
SCHED_FEAT_NEW_FAIR_SLEEPERS= 1,
SCHED_FEAT_WAKEUP_PREEMPT = 2,
SCHED_FEAT_START_DEBIT = 4,
SCHED_FEAT_TREE_AVG = 8,
Hi Ingo,
I'll get the results tomorrow as I'm now out of the office, but
I can perhaps answer some of your queries now.
On Jan 15, 2008 10:06 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, the system has considerable idle time left:
>
> r b swpd free buff cache si so bi bo in
* Colin Fowler <[EMAIL PROTECTED]> wrote:
> These data may be much better for you. It's a single 15 second data
> collection run only when the actual ray-tracing is happening. These
> data do not therefore cover the data structure building phase.
>
> http://vangogh.cs.tcd.ie/fowler/cfs2/
hm,
These data may be much better for you. It's a single 15 second data
collection run only when the actual ray-tracing is happening. These
data do not therefore cover the data structure building phase.
http://vangogh.cs.tcd.ie/fowler/cfs2/
Colin
On Jan 14, 2008 10:42 PM, Colin Fowler <[EMAIL
These data may be much better for you. It's a single 15 second data
collection run only when the actual ray-tracing is happening. These
data do not therefore cover the data structure building phase.
http://vangogh.cs.tcd.ie/fowler/cfs2/
Colin
On Jan 14, 2008 10:42 PM, Colin Fowler [EMAIL
* Colin Fowler [EMAIL PROTECTED] wrote:
These data may be much better for you. It's a single 15 second data
collection run only when the actual ray-tracing is happening. These
data do not therefore cover the data structure building phase.
http://vangogh.cs.tcd.ie/fowler/cfs2/
hm, the
Hi Ingo,
I'll get the results tomorrow as I'm now out of the office, but
I can perhaps answer some of your queries now.
On Jan 15, 2008 10:06 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
hm, the system has considerable idle time left:
r b swpd free buff cache si so bi bo in
Hi Ingo, thanks for the reply.
Modifying /proc/sys/kernel/sched_latency_ns to be double may have in
fact made things slightly worse. I used 24-rc7
Your script was only written to run for 15 seconds, so I ran it so it
multiple times so it covered most of the benchmark.
Other issues with these
Forgot to add that the results are at http://vangogh.cs.tcd.ie/fowler/cfs/
On Jan 14, 2008 10:42 PM, Colin Fowler <[EMAIL PROTECTED]> wrote:
> Hi Ingo, thanks for the reply.
>
> Modifying /proc/sys/kernel/sched_latency_ns to be double may have in
> fact made things slightly worse. I used 24-rc7
* Colin Fowler <[EMAIL PROTECTED]> wrote:
> Benchmark : A ray-trace is performed on 500 times on 17 separate
> scenes. Workload is distributed by tiling the framebuffer into N 32x32
> pixel tiles. Each CPU grabs one of N tiles out of the queue and
> repeats until no jobs are left. Rendering
Please CC me as I'm not subscribed.
I have (what is to me) a strange and very repeatable slowdown for a
CPU intensive benchmark on my system on newer kernels.
Hardware : Dell Precision 470.
CPU 2x2.0GHz Quad Core Xeon E5335 CPUs
Memory 4GB ECC RAM.
OS Ubuntu x86_64 7.10 (Gutsy Gibbon)
Compiler
Please CC me as I'm not subscribed.
I have (what is to me) a strange and very repeatable slowdown for a
CPU intensive benchmark on my system on newer kernels.
Hardware : Dell Precision 470.
CPU 2x2.0GHz Quad Core Xeon E5335 CPUs
Memory 4GB ECC RAM.
OS Ubuntu x86_64 7.10 (Gutsy Gibbon)
Compiler
Hi Ingo, thanks for the reply.
Modifying /proc/sys/kernel/sched_latency_ns to be double may have in
fact made things slightly worse. I used 24-rc7
Your script was only written to run for 15 seconds, so I ran it so it
multiple times so it covered most of the benchmark.
Other issues with these
Forgot to add that the results are at http://vangogh.cs.tcd.ie/fowler/cfs/
On Jan 14, 2008 10:42 PM, Colin Fowler [EMAIL PROTECTED] wrote:
Hi Ingo, thanks for the reply.
Modifying /proc/sys/kernel/sched_latency_ns to be double may have in
fact made things slightly worse. I used 24-rc7
Your
25 matches
Mail list logo
