LKML Archive on lore.kernel.org help / color / mirror / Atom feed
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 [test] hackbench.c interactivity results: vanilla versus SD/RSDL 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: linkBe 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; as well as URLs for NNTP newsgroup(s).