Hi Antoine, Ingo,


On 9/14/07, Ingo Molnar <mingo@elte.hu> wrote:
quoted text
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > hm, could you try the patch below ontop of 2.6.23-rc6 and do:
> >
> >  echo 1 > /proc/sys/kernel/sched_yield_bug_workaround
> >
> > does this improve the numbers?

Hmm, I know diddly about Java, and I don't want to preempt Antoine's next
test, but I noticed that he uses Thread.sleep() in his testcode and not the
Thread.yield() so it would be interesting if Antoine can test with this patch
and report if something shows up ...


quoted text
> the patch i sent was against CFS-devel. Could you try the one below,
> which is against vanilla -rc6, does it improve the numbers? (it should
> have an impact) Keep CONFIG_SCHED_DEBUG=y to be able to twiddle the
> sysctl.


On 9/13/07, Antoine Martin <antoine@nagafix.co.uk> wrote:
quoted text
>
> All the 2.6.23-rc kernels performed poorly (except -rc3!):

This is an interesting data point, IMHO ... considering these tests are long,
I suspect you ran them only once each per kernel. So I wonder how reliable
that -rc3 testpoint is. If this oddity is reproducible, it would be great if you
could git-bisect:

1. between 23-rc1 and 23-rc3, and find out which commit led to the
  improvement in performance, and,
2. between 23-rc3 and 23-rc6, and find out which commit brought down
  the numbers again.

[ http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html,
  git-bisect is easy and amazingly helpful on certain occasions. ]


quoted text
> Notes about the tests and setup:
> * environment is:
> Dual Opteron 252 with 3GB ram, scsi disk, etc..
> Sun Java 1.6
> MySQL 5.0.44
> Junit + ant + my test code (devloop.org.uk)
> * java threads are created first and the data is prepared, then all the
> threads are started in a tight loop. Each thread runs multiple queries
> with a 10ms pause (to allow the other threads to get scheduled)

Don't know much about CFS either, but does that constant "10 ms" sleep
somehow lead to evil synchronization issues between the test threads?
Does randomizing that time (say from 2-20 ms) lead to different numbers?


quoted text
> * load average is divided by the number of cpus (2)
> * more general information (which also covers some irrelevant
> information about some other tests I have published) is here:
> http://devloop.org.uk/documentation/database-performance/Setup/


Thanks,

Satyam
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/