From: Xenofon Antidides <xantidides@yahoo.gr>
To: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>, Con Kolivas <kernel@kolivas.org>,
linux list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [test] hackbench.c interactivity results: vanilla versus SD/RSDL
Date: Fri, 30 Mar 2007 19:36:14 -0700 (PDT) [thread overview]
Message-ID: <20070331023615.98478.qmail@web26704.mail.ukl.yahoo.com> (raw)
In-Reply-To: <1175273215.7185.3.camel@Homer.simpson.net>
[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]
--- Mike Galbraith <efault@gmx.de> wrote:
> On Fri, 2007-03-30 at 15:05 +0000, Xenofon Antidides
> wrote:
> > ----- Original Message ----
> > From: Ingo Molnar <mingo@elte.hu>
> > To: Con Kolivas <kernel@kolivas.org>
> > Cc: linux list <linux-kernel@vger.kernel.org>;
> Andrew Morton <akpm@linux-foundation.org>; Mike
> Galbraith <efault@gmx.de>
> > Sent: Thursday, March 29, 2007 9:22:49 PM
> > Subject: [test] hackbench.c interactivity results:
> vanilla versus SD/RSDL
> >
> >
> > * Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > * Con Kolivas <kernel@kolivas.org> wrote:
> > >
> > > > I'm cautiously optimistic that we're at the
> thin edge of the bugfix
> > > > wedge now.
> > [...]
> >
> > > and the numbers he posted:
> > >
> > >
>
http://marc.info/?l=linux-kernel&m=117448900626028&w=2
> >
> > We been staring at these numbers for while now and
> we come to the conclusion they wrong.
> >
> > The test is f is 3 tasks, two on different and one
> on same cpu as sh here:
> > virgin 2.6.21-rc3-rsdl-smp
> > top - 13:52:50 up 7 min, 12 users, load average:
> 3.45, 2.89, 1.51
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM
> TIME+ P COMMAND
> > 6560 root 31 0 2892 1236 1032 R 82 0.1
> 1:50.24 1 sh
> > 6558 root 28 0 1428 276 228 S 42 0.0
> 1:00.09 1 f
> > 6557 root 30 0 1424 280 228 R 35 0.0
> 1:00.25 0 f
> > 6559 root 39 0 1424 276 228 R 33 0.0
> 0:58.36 0 f
>
> This is a 1 second sample, tasks migrate.
>
> -Mike
Something different on many cpus? Sorry I was thinking
something other. I try 50% run + 50% sleep on one cpu
and mainline has big problem. Sorry for bad code I
copy bits to make it work. Start program first then
run bash 100% cpu (while : ; do : ; done). Try change
program forks from 1 till 3 or more mainline kernel
and bash gets 0%.
Xant
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 1949799762-fiftyp.c --]
[-- Type: text/x-csrc; name="fiftyp.c", Size: 2772 bytes --]
// gcc -O2 -o fiftyp fiftyp.c -lrt
// code from interbench.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
int forks=1;
int runus,sleepus=7000;
unsigned long loops_per_ms;
void terminal_error(const char *name)
{
fprintf(stderr, "\n");
perror(name);
exit (1);
}
unsigned long long get_nsecs(struct timespec *myts)
{
if (clock_gettime(CLOCK_REALTIME, myts))
terminal_error("clock_gettime");
return (myts->tv_sec * 1000000000 + myts->tv_nsec );
}
void burn_loops(unsigned long loops)
{
unsigned long i;
/*
* We need some magic here to prevent the compiler from optimising
* this loop away. Otherwise trying to emulate a fixed cpu load
* with this loop will not work.
*/
for (i = 0 ; i < loops ; i++)
asm volatile("" : : : "memory");
}
/* Use this many usecs of cpu time */
void burn_usecs(unsigned long usecs)
{
unsigned long ms_loops;
ms_loops = loops_per_ms / 1000 * usecs;
burn_loops(ms_loops);
}
void microsleep(unsigned long long usecs)
{
struct timespec req, rem;
rem.tv_sec = rem.tv_nsec = 0;
req.tv_sec = usecs / 1000000;
req.tv_nsec = (usecs - (req.tv_sec * 1000000)) * 1000;
continue_sleep:
if ((nanosleep(&req, &rem)) == -1) {
if (errno == EINTR) {
if (rem.tv_sec || rem.tv_nsec) {
req.tv_sec = rem.tv_sec;
req.tv_nsec = rem.tv_nsec;
goto continue_sleep;
}
goto out;
}
terminal_error("nanosleep");
}
out:
return;
}
/*
* In an unoptimised loop we try to benchmark how many meaningless loops
* per second we can perform on this hardware to fairly accurately
* reproduce certain percentage cpu usage
*/
void calibrate_loop(void)
{
unsigned long long start_time, loops_per_msec, run_time = 0;
unsigned long loops;
struct timespec myts;
loops_per_msec = 1000000;
redo:
/* Calibrate to within 1% accuracy */
while (run_time > 1010000 || run_time < 990000) {
loops = loops_per_msec;
start_time = get_nsecs(&myts);
burn_loops(loops);
run_time = get_nsecs(&myts) - start_time;
loops_per_msec = (1000000 * loops_per_msec / run_time ? :
loops_per_msec);
}
/* Rechecking after a pause increases reproducibility */
sleep(1);
loops = loops_per_msec;
start_time = get_nsecs(&myts);
burn_loops(loops);
run_time = get_nsecs(&myts) - start_time;
/* Tolerate 5% difference on checking */
if (run_time > 1050000 || run_time < 950000)
goto redo;
loops_per_ms=loops_per_msec;
sleep(1);
start_time=get_nsecs(&myts);
microsleep(sleepus);
run_time=get_nsecs(&myts)-start_time;
runus=run_time/1000;
}
int main(void){
int i;
calibrate_loop();
printf("starting %d forks\n",forks);
for(i=1;i<forks;i++){
if(!fork())
break;
}
while(1){
burn_usecs(runus);
microsleep(sleepus);
}
return 0;
}
next prev parent reply other threads:[~2007-03-31 2:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-30 15:05 Xenofon Antidides
2007-03-30 16:46 ` Mike Galbraith
2007-03-31 2:36 ` Xenofon Antidides [this message]
2007-03-31 3:23 ` Mike Galbraith
2007-03-31 3:42 ` Mike Galbraith
2007-03-31 6:08 ` Mike Galbraith
2007-03-31 5:41 ` Xenofon Antidides
2007-03-31 6:31 ` Mike Galbraith
2007-03-31 6:49 ` Mike Galbraith
2007-03-31 9:28 ` Xenofon Antidides
2007-03-31 9:43 ` Ingo Molnar
2007-03-31 9:48 ` [patch] sched: improve fairness, v3 Ingo Molnar
2007-03-31 10:11 ` Ingo Molnar
2007-03-31 10:05 ` [test] hackbench.c interactivity results: vanilla versus SD/RSDL Ingo Molnar
2007-04-03 2:34 ` Con Kolivas
2007-04-03 5:24 ` Mike Galbraith
2007-03-31 5:04 ` Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2007-03-29 11:22 Ingo Molnar
2007-04-03 1:07 ` Con Kolivas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070331023615.98478.qmail@web26704.mail.ukl.yahoo.com \
--to=xantidides@yahoo.gr \
--cc=akpm@linux-foundation.org \
--cc=efault@gmx.de \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®