linux-kernel - Re: CFS: some bad numbers with Java/database threading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a781481a0709140306k3faf3585haae26853fe81381c@mail.gmail.com>
Date:	Fri, 14 Sep 2007 15:36:42 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Antoine Martin" <antoine@...afix.co.uk>,
	"Linux Kernel Development" <linux-kernel@...r.kernel.org>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Subject: Re: CFS: some bad numbers with Java/database threading

Hi Antoine, Ingo,

On 9/14/07, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Ingo Molnar <mingo@...e.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 ...

> 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@...afix.co.uk> wrote:
>
> 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. ]

> 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?

> * 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/